Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

政府とデジタルウォレットのあり方に関するOIXのレポートを読む(6)

$
0
0

こんにちは、富士榮です。

ここまで見てきたOIX(Open Identity Exchange)のレポートもついに最終回です。

これまでのおさらいはこちらです。


今回はレポートが出している結論についてみていきましょう。

エグゼクティブサマリーでも触れましたが、本レポートにおける結論・提言は、

  • 政府は独自にウォレットを開発し市民に向けて提供すべきではない
  • その代わりに政府はトラストフレームワークを定義し、認定された民間のウォレットに政府発行のクレデンシャルを格納できるようにするべきである
です。

このことによる利点が以下の通り説明されています。

政府にとっての利点
  • ウォレットの開発・維持のためのコストがかからない
  • 政府がID データを含む政府が発行したクレデンシャルのセキュリティに重点を置くこと で、民間のウォレットプロバイダは、そのデータを安全かつコスト効率よく扱うために必要なウォレッ ト、デバイス、およびアプリケーション開発に重点を置くことができる
  • 民間のウォレットプロバイダは分散型のユーザー中心データ管理を実装することを求められ、分散型ID管理へのアプローチがより進行する
  • 民間企業のウォレットの市場投入速度を活用することで、デジタル・エコシステムをより 迅速に実現できる
  • 競争力のある民間ウォレットにより、デジタルIDサービスのイノベーションが可能になる
  • 政府は、認定されたウォレットへの政府クレデンシャルの発行に集中できる
  • 民間企業の方が、さまざまな配信方法(スマートフォン以外、クラウド・ウォレッ トなど)に合わせたデジタルIDシステムを進化させるのに適している。スマートフォンはIDウォレットの前提条件ではないため、より包括的なアプローチとなる
  • 納税者が資金を提供するIDユーティリティではなく、経済成長を可能にする民間セクターのウォレット市場を創出する
  • アクセシビリティと権限の委譲は、専門的な民間プロバイダによって実現される
  • 政府のIDウォレットが技術やイノベーションの停滞に苦しむリスクを軽減する
  • 政府が提供するウォレッ トでは個人と法人の関係性を明確にするにあたり複雑な問題に対処しなければならなかったり、個人とLEIの関係の政府への透明性を排除する必要があったりする一方で民間のウォレットプロバイダでは個人と個人が代表する企業とをリンクさせることができる
  • 民間のウォレットは国境を越えて機能し、シームレスな方法で非国民のサービスへのアクセ スを可能にし、更なる経済成長を可能にする
利用者にとっての利点
  • すべてのクレデンシャルを1つのウォレットで管理することを選択でき、複数のクレデンシャルのやり取りをする際もシームレスな体験を得ることができる。複数のウォレットを使い分けようと思えば使い分けることもできる。例えば、旅行する際は別のウォレットを使い、ビジネス目的には別のウォレットを利用することもできる。ユーザーは政府のトラストフレームワークを活用し、自分が信頼できるブランドのウォレットを選ぶことができる
  • 民間のユースケースで政府が発行したクレデンシャルの使用を政府がトラッキングするのではないか、という懸念を持つことはほとんどなくなる
  • 一方でクレデンシャルのユースエースに幅がありすぎるため、単一のウォレットですべてのユースケースを満たすことはできないのでは?という考え方も存在する。しかし、このアプローチでは、旅行、健康、教育などそれぞれの目的に応じて政府が認定したウォレットを利用し、それぞれが関連する政府発行のクレデンシャルを保存するこも可能である
  • 利用者やプライバシー保護運動家、メディアは、政府が提供するウォレットを利用することで政府がマスターとなるIDデータベースを持つことになると認識していないし、利用者の行動を追跡できるとも認識していない。このような潜在的なリスクに対する対策となる
リライングパーティ(提示先)にとっての利点
  • 単一のウォレットとだけ連動することで、複数のクレデンシャルを要求するトランザクションに必要なクレデンシャルの全て(単一ウォレットに格納されている場合)にアクセスできるようになり、その結果、クレデンシャルと統合にかかるコストが安くなる
  • 複数クレデンシャルを利用する際の複雑なルール(例えば、XYZに旅行するにはパスポートとワクチン接種証明書が必要、など)に対応する際に必要な処理をウォレット側に移譲することができる(自前で複数クレデンシャルを収集するロジックを実装する必要がない)
  • 同時に間違ったデータや不正なデータに対する責任を民間のIDプロバイダに委譲することもできる可能性もある。(このような場合、政府が提供するウォレットでは政府に責任を追求するのは極めて難しい)
  • 市場投入までの時間が短くなる可能性がある。デジタルIDウォレットをより多くのユーザーがより迅速に利用できるようになる
  • 政府システムの考え方で先行しがちな、サポートされる最も古いバージョンのセキュリ ティではなく、継続的なイノベーションによるセキュリティを考慮することができる
  • リライングパーティは商業的な選択肢とレバレッジを持つことで、クレデンシャルの市場価格を 競争力のあるものに保つことができる。脆弱なウォレットプレーヤーは、市場の力によって是正されるか拒否されることとなる

また、このモデルは政府が提供するトラストフレームワークが有効に機能していることを前提としているわけですが、そのトラストフレームワークが有効に働くためには透明性も必要となってくると思われます。
例えば、

  • トラストフレームワークに監視する仕組みを組み込む
  • ポータビリティ要件を通じて、あるウォレットから別のウォレットへクレデンシャルを移動できることを保証する
  • クレデンシャルがいつどこで使用されたかを政府が知ることなく、どのエンティティが政府クレ デンシャルを使用できるかを管理することをトラストフレームワークに組み込む
  • 信頼性を担保できないウォレットから政府がクレデンシャルを抜き去る仕組みをトラストフレームワークへ組み込む

  • 最後にレポートは以下の文で締め括っています。
    政府によっては、この枠組みの下で独自のIDウォレットを発行することで、市民が市場で利用可能なウォレットを民間セクター以外の選択肢から選べるようにすることを選ぶかもしれない。しかし、利用者に代替手段を与えることは良いアイデアかもしれないが、それは政府が独自のウォレットを発行し管理するためのコストと技術の進歩へ対処する必要があることを意味する。つまり、大きな利点と緩和可能な管理上の懸念があるため、政府が認定したフレームワーク(またはスキーム)の下で承認された民間のウォレットを利用できるようにすることが、政府、その国民、依存する当事者双方にとって最善のアプローチであると結論付けられる。

    必ずしも日本においてこれらが当てはまるとは思いませんが、特定の思想や過去の慣習などに囚われることなく合理的に検討を進められると良いですね。



    Vittorio Awardの募集が始まっています

    $
    0
    0
    こんにちは、富士榮です。

    皆さんはVittorio Bertocciを覚えているでしょうか?私は忘れたくても忘れられない貴重な友人であり教師の一人です。
    もちろん同時に彼はアイデンティティ界においても稀有な存在であり、彼が遺した功績を語り継ぐ意味でDigital Identity Adavancement Foundationが立ち上げたのがVittorio Awardです。(同様の取り組みにKim Cameron Awardもあります)



    4月9日から応募が始まっているので、アイデンティティ界で今後活躍していきたい、という意思のある方はぜひとも応募してみてはいかがでしょうか?


    The mission of the Vittorio Bertocci Award is to honor Vittorio Bertocci’s legacy by inspiring and supporting the next generation of identity experts who will shape the foundation of digital identity.
    Vittorio was a passionate, lifelong contributor to the internet as we know it by continuously engaging with and educating others about digital identity standards. He maintained laser focus on ensuring standards solved real-world problems and bettered the lives of developers tasked with their implementation. His singular charisma and wit guaranteed his lectures were memorable, which he shared all over the globe. By sponsoring motivated individuals to participate in identity standards organizations and events, the Vittorio Bertocci award creates opportunities for new voices to carry on this legacy of contributing to and learning from the standards development process.
    DIAF will begin to accept applicants for the Vittorio Bertocci Award on April 9th 2024, and we will provide more details at that time.
    Lastly, we believe that digital identity can only work for everyone when it’s built by everyone. We encourage people of all cultural, racial, gender identity, sexual orientation, age, veteran status, nationality, and religious backgrounds to apply.
    Vittorio Bertocci Award の使命は、デジタル ID の基礎を形成する次世代の ID 専門家を鼓舞し支援することで、Vittorio Bertocci の遺産を称えることである。
    Vittorio Bertocci は、デジタル・アイデンティティの標準について継続的に他者と関わり、他者を教育することで、私たちが知っているインターネットに情熱的かつ生涯を通じて貢献した人物です。彼は、標準が現実世界の問題を確実に解決し、その実装を任された開発者の生活を向上させることにレーザーの焦点を当て続けた。彼の類まれなカリスマ性とウィットは、彼の講義が記憶に残るものであることを保証し、世界中でそれを共有した。ヴィットリオ・ベルトッチ賞は、アイデンティティ標準化団体やイベントに参加する意欲的な個人を後援することで、標準化開発プロセスへの貢献とそこから学ぶというこの遺産を受け継ぐ新しい声の機会を創出します。
    DIAF は、2024 年 4 月 9 日に Vittorio Bertocci 賞への応募者の受付を開始する予定であり、その時 に詳細をお知らせします。
    最後に、デジタル・アイデンティティは、すべての人によって構築されて初めて、すべての人のために機能すると私たちは信じています。あらゆる文化、人種、性自認、性的指向、年齢、退役軍人の地位、国籍、宗教的背景を持つ人々の応募を奨励します。(Deeplによる機械翻訳)
     

    OpenID Summit Tokyo 2024の動画を公開されています

    $
    0
    0

    こんにちは、富士榮です。


    OpenID Summit Tokyo 2024の動画アーカイブが続々と公開されています。

    当日は対面のみの開催だったこともあり、ご来場いただけなかった方々、大変お待たせいたしました。


    関連ポスト)

    OpenID Summit Tokyo 2024クィックレビュー

    https://idmlab.eidentity.jp/2024/01/openid-summit-tokyo-2024.html


    こちらで公開されていますのでぜひご覧ください。

    そしてチャンネル登録をよろしくおねがいします!!

    https://www.youtube.com/@openidfoundationjapan7822

    Internet2からNext-Generation Credentials WGのレポートが発行されました

    $
    0
    0
    こんにちは、富士榮です。

    Internet2からNext Generation Credentialsに関するレポートが出ています。


    参考)Internet2
    セキュアな高速ネットワーク、クラウド・ソリューション、研究サポート、研究・教育向けのサービスを提供するコミュニティです。私たちのコミュニティには、高等教育機関、研究機関、政府機関、企業、文化団体が含まれます。Internet2は、正式名称をUniversity Corporation for Advanced Internet Development (UCAID)といい、多様なメンバーを代表する理事会によって運営される非営利団体です

    参考)InCommon

    InCommonは、Internet2が1998年から取り組んできたリソースへの信頼されたアクセスの研究から生まれた。2000年、Internet2はケン・クリンゲンシュタインを主任研究員として、後に10件となる連邦政府機関からの賞の第一号を受賞した。この賞の内訳は、全米科学財団から9件、商務省から1件である。これがInternet2 Middleware Initiativeの設立につながり、ShibbolethとInCommonの両方がこのプログラムから早い時期に生まれました。

     

    InCommonを通じて、Internet2は、シングルサインオン(SSO)、クラウドおよびローカルサービスへのアクセス、ローミングWi-Fiなど、研究および教育用に構築されたセキュリティ、プライバシー、IAMツールを提供しています。

    参考)CACTI
    Community Architecture Committee for Trust and Identity
    https://spaces.at.internet2.edu/display/CACTI

    CACTI(Community Architecture Committee for Trust and Identity)は、Internet2のトラスト・アイデンティティ担当副社長によって設立された、コミュニティメンバーによる常設のアーキテクチャ戦略グループである。CACTIは、他のグループやInternet2のトラスト・アイデンティティ担当副社長との交流を通じて、Internet2のトラスト・アイデンティティプログラム分野に助言を与える。CACTI のメンバーには、研究および教育からの幅広い代表が含まれる。詳細については、CACTI憲章を参照。

    と言う事でレポートです。
    https://spaces.at.internet2.edu/display/TI/TI.176.1

    Presentation Exchange v2.1のWorking Group Approvalに到達しました

    $
    0
    0

    こんにちは、富士榮です。

    OpenID for Verifiable Presentationsでも利用されているPresentation Exchangeのversion 2.1がDecentralized Identity Foundation(DIF)のWorking Group Approvalのステージに到達したようです。着々と進んでいるようですね。


    Presentation Exchange(ページ上は2.X.Xとなっていますがアナウンスでは2.1となっています)

    https://identity.foundation/presentation-exchange/

    参考)Working Group Approval

    DIFの仕様の開発ステップがこちらに定義されています。Final Approvalの一つ手前ですね。

    https://github.com/decentralized-identity/org/blob/master/work-item-lifecycle.md?ref=blog.identity.foundation#73-working-group-approval


    何が追加されたのか?についてDIFのNews letterには以下の記載があります。

    Security Enhancements: We have introduced a "Security Considerations" section, helping users navigate the security implications of the exchange more effectively.

    Expanded Use Cases: A new "Use Cases" section has been added. This aims to broaden the understanding and applicability of the Presentation Exchange, providing examples and scenarios where it can be implemented.

    Editorial Improvements: To further enhance the readability and clarity of the documentation, we have made various editorial changes throughout the text.

    セキュリティの強化: セキュリティに関する考慮事項」のセクションを導入し、交換のセキュリティへの影響をより効果的にナビゲートできるようになりました。

    使用例の拡大: 使用例」のセクションが追加されました。これは、Presentation Exchangeの理解と適用範囲を広げることを目的としており、Presentation Exchangeを実装できる例やシナリオを提供しています。

    編集の改善: ドキュメントの読みやすさとわかりやすさをさらに向上させるため、本文全体にわたってさまざまな編集上の変更を加えました。

    (Deeplで機械翻訳) 


    なお、Presentation Exchange 1系から2系での変化点は仕様のドキュメントの中にも記載があるので今後実装する方は参考にしていきましょう。https://identity.foundation/presentation-exchange/#what-is-new


    ドイツ/SPRINDのEUデジタルIDウォレットのプロトタイプ実装支援プログラム

    $
    0
    0
    こんにちは、富士榮です。

    日本でもデジタルIDウォレットの調査研究が進んだりしていますが、そのベースとも言えるEUデジタルIDウォレット(EUDIW)ではEUとしてARF(アーキテクチャ・リファレンス・フレームワーク)や、先日本ブログでも紹介したリファレンス実装のコードがgithubで公開されたりしており、EU加盟国は各国で実際に利用するためのウォレットの開発をそれぞれ進めていこうとしています。

    今回紹介するのはドイツにおける取り組みです。ドイツのSPRIND(FEDERAL AGENCY FOR DISRUPTIVE INNOVATION。イノベーション研究所的な位置付け、でいいのかな?)が5月5日を締め切りとして参加チームを募集している「FUNKE EUDI WALLET PROTOTYPES」というプログラムがあります。


    スローガンとして
    「Develop the most trustworthy, user-friendly, and universally applicable European Digital Identity Wallet for users in Germany!(ドイツのユーザーのために、最も信頼でき、ユーザーフレンドリーで、普遍的に適用可能なEUデジタル ID ウォレットを開発する!)」
    なんてことが書かれていて、盛り上げようとしている感じが好感が持てます。

    プログラムの期間は13カ月で、3つのステージに分かれているそうです。第1ステージでは1チームあたり最大30万ユーロを、第2ステージでは1チームあたり最大30万ユーロ、第3ステージでは1チームあたり最大35万ユーロの資金援助を行う予定のようです。

    応募要件を見ると特にEUやドイツ在住の企業や組織である必要はないようなのですが、まぁ、あんまり国外のベンダがドイツ国民のためのウォレットを開発するっていう姿も想像しにくいので実際はドイツのチームがやるんでしょうねぇ。


    政府と民間企業がウォレット提供者としてどのような形で関わるべきか?というOIXのレポートを先日紹介しましたが、このように民間をうまく巻き込んだエコシステムを作っていく取り組みは日本でも参考にしていけるといいですね。

    トラスト・スパニング・プロトコルのImplmentor's draftがアナウンスされています

    $
    0
    0

    こんにちは、富士榮です。

    Trust Over IPファウンデーションが今週開催されるIIW(Internet Identity Workshop)に合わせてトラスト・スパニング・プロトコルのImplementor's draftをアナウンスしてきました。アナウンスに使われたToIPのブログが非常にわかりやすいのそのまま機械翻訳にかけてみました。※そして私は現在IIWに参加するためマウンテンビューに来ています。

    こちらが原文です。

    TOIP ANNOUNCES THE FIRST IMPLEMENTERS DRAFT OF THE TRUST SPANNING PROTOCOL SPECIFICATION

    https://trustoverip.org/blog/2024/04/11/toip-announces-the-first-implementers-draft-of-the-trust-spanning-protocol-specification/


    早速中身を見ていきます。



    なぜトラスト・スパニング・プロトコルが必要なのか?

    インターネットがグローバルな情報経済を完全に変貌させたことに疑問を抱く人はいないだろう。接続性と信頼性の高いコンテンツ配信に不可欠なものとなった。しかし、インターネットが成長するにつれて、インターネットに対する脅威や、何を信頼すべきかという難しい課題も増えてきた。

    現在、AIはこうした懸念をさらに加速させている。CyberArkによる2023年の調査によると、セキュリティ専門家の93%が2023年にAIを活用した脅威が組織に影響を及ぼすと予想しており、AIを活用したマルウェアが懸念事項の第1位に挙げられている。業界の著名人であるマーク・アンドリーセンは最近、AIの偽物を検出するための戦争は勝ち目がない、唯一の解決策はコンテンツの真正性を証明できるようにすることで「問題を逆転」させる方法を見つけることだと述べた。

    30年もの間、セキュリティの問題は着実に深刻化しているのに、なぜ業界はまだ解決策を持っていないのだろうか?DNSSECや TLSのような技術や、IETFや CA/Browser Forumのような業界団体があるにもかかわらず、データ漏洩、ランサムウェア攻撃、個人情報盗難、マルウェアの蔓延に関する見出しが毎日のように掲載されるのはなぜでしょうか?生成AIへの関心が爆発的に高まっているにもかかわらず、なぜ多くの専門家は、AIが私たちを守るためというよりも、私たちを攻撃するために使われることを心配しているのだろうか?

    その答えが、ToIP(Trust Over IP)ファウンデーションが4年前に設立された理由である。要するに、真正性、機密性、およびメタデータ・プライバシー機能は、インターネットのコア構造に組み込まれることはなかったのです。この問題の根本を解決するためには、既存のインターネットの上に次世代のトラストレイヤーが必要である。

    このレイヤーの中心は、インターネット・プロトコル(IP)がデジタル・データにとってそうであるように、デジタル・トラストにとってそうであるプロトコルである。それがToIPトラスト・スパニング・プロトコル(TSP)である。


    TSPのハイレベルな概要はどこで入手できますか?

    まず、2023年1月にToIPトラスト・スパニング・プロトコル・タスクフォース(TSPTF)を立ち上げた際に発表したこのブログ記事から確認できる。TSPの全体的な目的と、ToIPスタックの中での位置づけが説明されている。

    次に、昨年8月に発表されたToIPトラスト・スパニング・プロトコルの中間進捗報告書を読んで、TSP設計の7つの柱を要約することができる。いくつかの用語の進化を除いて、これら7つの柱は、過去7ヶ月間、複数の段階のワーキングドラフトを経てきた中で変わっていない。

    本日、最初のImplementor's draftを発表できることを嬉しく思う。


    Implmentor's draftは何をカバーしているのか?

    この表は、仕様書の10の主要セクションをまとめたものである:

    • 検証可能な識別子(VID)
      • VID は7 つの柱の最初のものであり、TSP に対する技術的な信頼を提供する暗号的に検証可能な識別子である。VID が必要な理由、VID が公開鍵と ToIP エンドポイント・アドレスへのアクセスを提供する方法、VID の検証方法、および鍵のローテーション方法について説明する。
    • メッセージ
      • TSPはメッセージベースの非同期通信プロトコルである。メッセージ・エンベロープ、ペイロード(機密、非機密、ヘッダー)、署名、リレーションシップのセットアップ、帯域外の紹介。
    • ネストされたメッセージ
      • TSPメッセージは、メタデータ・プライバシーを達成するために1層または2層にネストすることができる。対象:ペイロード・ネスト、ネストされた関係 VID。
    • 仲介者を経由するメッセージ
      • TSPメッセージは、非同期配信、信頼性、パフォーマンスなど、いくつかの理由で仲介者を経由することができる。しかし、主な焦点はメタデータのプライバシー保護である。対象範囲:メッセージルーティング、直接の隣接関係、エンドポイント間(「トンネルされた」)メッセージ、プライベートVID、単一の仲介者、2つ以上の仲介者。
    • マルチ・レシピエント・コミュニケーション
      • TSP メッセージは複数の受信者に送ることができる。対象:複数受信者リストとエニーキャスト仲介。
    • 制御ペイロードフィールド
      • TSPメッセージは多目的であるため、専用の 制御メッセージではなく、制御ペイロードを定義する 。リレーションシップの形成(パラレル、ネスト、サードパーティの紹介)、リレーションシップのイベント(キーの更新、ルーティング情報、リレーションシップのキャンセル)。
    • 暗号アルゴリズム
      • TSPの真正性と機密性の特性は、公開鍵/秘密鍵暗号に依存しています。公開鍵署名、公開鍵認証暗号化、暗号化と復号のプリミティブ、ハイブリッド公開鍵暗号化(HPKE)、Libsodiumシールドボックス。
    • シリアライズとエンコーディング
      • TSPは 、 メッセージのシリアライズとエンコーディングにCESR(Composable Event Streaming Representation)を使用 します。CESRは、JSON、CBOR、MsgPakなどの一般的なデータ・エンコーディング・フォーマットをサポートします。対象:エンベロープ・エンコーディング、ペイロード・エンコーディング(非機密、機密、ネスト)、署名エンコーディング。
    • トランスポート
      • TSPの真正性、機密性、メタデータ・プライバシー特性は、トランスポート・プロトコルの選択に依存しないように設計されている。対象:トランスポート・サービス・インターフェース、トランスポート・メカニズムの例。
    • 付録)テストベクター
      • (まだ完成していない)一般的なユースケースのテストベクタ。ダイレクトモードのメッセージ、ダイレクトモードのネストされたメッセージ、ルーティングされたモデルのメッセージ。

    TSPは他のトラスト・プロトコルとどう違うのか?

    デジタル・トラストのための基本的な新しいインターネット規模のプロトコルを提案することは、野心的な事業です。なぜToIPファウンデーションはこのような道を選んだのだろうか?まず、この分野の関連する取り組みから見ていこうと思う。

    関連プロトコル

    この表は、デジタルトラストの様々な側面に取り組む他の有名なプロトコルをまとめたものです:
    • OpenID Connect(OIDC)
      • データ形式としてJSONを使用するRESTful HTTP APIとしてOpenID Foundationによって指定されたOAuth 2.0認可フレームワークの上にある認証レイヤ。基本的なユーザプロファイル情報へのアクセスをサポートします。オプションのYeahHighlight機能には、IDデータの暗号化、OpenIDプロバイダの発見、セッション管理などがある。
    • OpenID for Verifiable Credentials(OID4VC)
      • 検証可能なデジタル証明書の発行(OID4VCI)と提示(OID4VP)のためにOIDCの上に構築されたOpenID Connectワーキンググループのプロトコルファミリーと、ウォレットベースのユーザー認証プロトコル(SIOP)。
    • DIDComm
      • Decentralized Identity Foundation(DIF)のDIDCommワーキンググループによって仕様化されたDIDCommは、エンドポイントがDID(分散識別子)によって指定されるピアツーピアのセキュアメッセージングプロトコルである。
    • TLS (Transport Layer Security)
      • 安全なHTTPSブラウザー接続を可能にすることでよく知られる IETF の暗号プロトコル。X.509デジタル証明書を使用することにより、セキュリティ、機密性、完全性、真正性を提供する。
    • MLS (Message Layer Security)
      • IETF のMLS ワーキンググループによって仕様化された MLS は、任意のサイズのグループにおいて、エンドツーエンドで暗号化されたメッセージを扱うセキュリティレイヤーである。MLS のセキュリティ特性には、メッセージの機密性、メッセージの完全性と認証、メンバー認証、非同期性、前方秘匿性、漏洩後のセキュリティ、スケーラビリティなどが含まれる。
    • RCS (Rich Communications Services)
      • GSMAが指定したテキストベースのモバイル・メッセージング・プロトコルで、SMSメッセージに代わり、通話中のマルチメディアを含む豊富な機能を提供する。RCSはネイティブではエンドツーエンドの暗号化をサポートしていない。Googleは独自の実装でSignal Protocolを使用して暗号化を追加した。アップルは、GSMAがエンドツーエンドの暗号化を標準化すれば、RCSをサポートすると述べている。
    • Signal Protocol
      • 音声およびインスタントメッセージの会話をエンドツーエンドで暗号化する、Signal Foundationによって指定された非連帯暗号プロトコル。このプロトコルは、ダブルラチェットアルゴリズム、プレキー、およびトリプル楕円曲線ディフィー・ヘルマン(3-DH)ハンドシェイクを組み合わせたものです。
    • Matrix Protocol
      • Matrix Foundationによって規定された連合リアルタイム通信のためのアプリケーション層通信プロトコルで、オープンなサーバフェデレーション上でJSON形式のメッセージを安全に配信し、永続化するためのHTTP APIを提供する。WebRTCを介して標準的なWebサービスと統合し、ブラウザ間のアプリケーションを容易にすることができる。
    • DNSSEC
      • ドメイン・ネーム・システム(DNS)で交換されるデータを保護するための、IETFによる拡張仕様のスイート。このプロトコルは、データの暗号認証、認証された存在拒否、データの完全性を提供するが、可用性や機密性は提供しない。
    • ISO/IEC 14443-4:2018
      • 非接触環境用に設計された半二重ブロック伝送プロトコルで、プロトコルの活性化シーケンスと非活性化シーケンスを定義する。ISO/IEC 14443 の他の部分との併用を意図しており、タイプ A とタイプ B の近接カードやオブジェクトに適用可能である。

    関連する暗号データ構造

    インターネット規模のデジタル・トラストに必要な要素はプロトコルだけではない。この表は、これまでに開発された標準的な暗号データ構造のいくつかをまとめたものである:
    • X.509デジタル証明書
      •  TLSを含む多くのインターネット・プロトコルで使用される公開鍵証明 書やデジタル署名の形式を定義するITU標準 。X.509証明書は、電子署名を使用して、ID(ホスト名、組織、個人)と公開鍵を結びつける。証明書は、認証局(CA)または自己署名によって署名される。X.509 は、 証明書失効 リストと 認証パス検証アルゴリズムも定義して いる。
    • 暗号化/署名されたPDFファイル
      •  ポータブル・ドキュメント・フォーマット(Portable Document Format)は、もともとアドビが開発したもので、2008年にISO標準となった。PDFファイルは暗号化することができる。PDF 2.0は標準として256ビットAES暗号化を定義しているが、サードパーティがPDF用に独自の暗号化システムを定義する方法も定義している。ISO 32000-2は、PDFファイルを安全な認証のためにデジタル署名する方法を定義している。
    •  検証可能なデジタル証明書
      •  デジタル・ウォレットの出現に 伴い、W3C 検証可能クレデンシャル・データ・モデル、 ISO mDL/mDOC、 IETF SD-JWT、 Hyperledger AnonCreds、 ToIP Authentic Chained Data Container(ACDC)など、暗号的に検証可能なデジタル・クレデンシャルのための複数のフォーマットが開発 されてきた。
    •  C2PAコンテンツ認証
      • C2PA標準は、暗号的に検証可能な出所情報をデジタルメディアコンテンツにバインドするモデルと、その情報の信頼性を評価するモデルを定義する。

     TSPはどう違うのか、なぜ違うのか?

    上記のセクションが示すように、インターネットの多数のセキュリティ、機密性、およびプライバシー問題に対処するために設計されたプロトコルと暗号データ構造には、何千人もの工数が費やされてきた。では、なぜToIPファウンデーションのメンバーは4年もの歳月をかけてTSPを開発したのだろうか?
    その基本的な理由をこの表にまとめた:
    •  上位層プロトコルのスパニング層としてのミニマリスト・デザイン
      •  TSPの唯一で最も重要な設計目標であり、(DIDCommを例外とする)上記のプロトコルとの最大の差別化要因は、プロトコルスタックにおけるスパニングレイヤーの重要な役割である。それが「可能な限りシンプルでなければならないが、これ以上シンプルであってはならない」理由は、ToIPスタックの設計原則の第3原則で詳しく説明されている。TSPが上記のプロトコルの機能の多くを含まないのは、まさにそれらの機能をより上位のプロトコルで提供できるように設計されているからである。その利点は、TSPレイヤーで達成された技術的な信頼機能をすべて自動的に継承するため、それらの上位プロトコルはすべて、よりシンプルで将来性のあるものにできるということである。
    •  分散型ピアツーピアアーキテクチャ
      •  HTTPとRESTful API上に構築されたOpenIDファミリーのプロトコルは、本質的にウェブ中心(クライアント/サーバー)である。TSPはそのようなアーキテクチャ上の仮定はしていない。IPプロトコルのように、どのような種類のネットワークやソフトウェア・アーキテクチャであっても、2つのピア間で動作することができる。
    • VIDsとDIDs
      •  DIDCommのように、すべてのTSPエンドポイントは、W3C Decentralized Identifiers(DIDs)仕様で定義されているような暗号的に検証可能な識別子(VID)を使用する。VIDは完全な分散化をサポートするだけでなく、ライフタイム・リレーションシップ管理のための移植性と暗号的な俊敏性を提供する。
    • 公開鍵認証による暗号化と署名
      • TSPは、最新の公開鍵認証暗号化と公開鍵署名を組み合わせて、鍵の漏洩によるなりすましと送信者のなりすましの両方に対する最強の保護を提供する。これは、IETF RFC9180HPKE(HypbridPublic Key Encryption)で定義されたAuth Modeプリミティブ、またはESSR(Encrypt Sender Sign Receiver)パターンで強化されたHPKE Base ModeまたはLibsodium Sealed Boxプリミティブのいずれかを使用することで実現される。
    • ペイロードの敏捷性
      • TSPは、JSON、CBOR、MsgPakを含むテキストとバイナリの両方のプリミティブを同じメッセージ内で合成することをサポートするCESRテキスト・バイナリ・デュアル・エンコーディング・フォーマットを使用する。
    • 暗号の俊敏性
      • CESRのもう一つの大きな特徴は、あらゆるタイプの暗号プリミティブに対応するコードテーブルである。例えば、CESRは上記の暗号データ構造のどれでも伝送することができる。これにより、TSPエコシステムは正確な署名と暗号化アルゴリズムを標準化しながらも、時とともに進化させることができる。
    • トランスポートの独立性
      • Trust Over IP "という名称は、トランスポートをTCP/IPスタックに依存することを示唆しているが、実際には、TSPの中核的な設計目標は、基礎となるトランスポート・プロトコルから完全に独立して、エンドツーエンドの真正性、機密性、およびメタデータ・プライバシーを提供することである。

    どのような実装プロジェクトが発表されましたか?

    最初の実装者ドラフトと並行して、来週のInternet Identity Workshop#38 では、TSP 仕様の主要著者の 1 人が主導する最初の 2 つの TSP 実装プロジェクトを発表する予定です:
    共著者のWenjing Chuが率いるRustオープンソース実装は、OWFプレミア・メンバーのFuturewei、Gen、AccentureがスポンサーとなるOpenWallet Foundation(OWF)の新しいプロジェクトとして提案されている。
    Pythonのオープンソース実装は、共著者のSam Smithと彼の同僚によってWeb of Trust GitHubコミュニティプロジェクトで開発されている。
    これらのプロジェクトのいずれかに貢献したり、独自のプロジェクトを立ち上げたりすることに興味がある方は、ぜひご協力していただきたい。ToIPのコンタクトページか GitHubからご連絡いただきたい。

    この草案について、どのようなフィードバックを求めていますか?

    いつものように、私たちは新しいプロトコル仕様に関する通常の質問に対するフィードバックを求めている:
    • 仕様は明確で理解しやすいか?
    • 仕様書は明確で理解しやすいか?
    • より多くの例や図解があれば助かる箇所はありますか?
    • 追加してほしい特定のテストベクターはありますか?
    また、特に以下の分野でのご意見を募集している:
    1. TSPをどのように利用しますか?すでに持っているものをどのように強化できるか?どのような種類のトラスト・タスク・プロトコルをTSPに重ねることに最も興味があるか?
    2. TSP は、計画しているトラスト・タスク・プロトコルをサポートするために必要なベースライン機能を提供するか?
    3. TSP はソリューションをより分散化することを可能とするか?
    4. どのような種類のVIDのサポートを実装する予定か?
    5. どのようなトランスポート・プロトコルにバインドする予定か?
    6. どのような暗号アルゴリズムを使用したいですか、または使用する必要があるか?
    7. 技術スタックで解決しようとしている問題で、既存のソリューションでは対処できず、TSPで対処できる、あるいは対処すべき問題は何か?
    8. 私たちが知らない他の開発中のプロトコルで、TSPと競合する、あるいはTSPを補完する可能性のあるものはあるか?

    どのようにフィードバックできますか?

    仕様を確認するには
    コメント、バグ報告、問題提起は、GitHubのToIPパブリックレビュープロセスに従うこと:


    ご覧の通り、割と広くトラストについてカバーされており、実際の仕様も出てきているので見ていけると良いと思います。













    OpenID Foundation Workshop@Googleクイックレビュー

    $
    0
    0
    こんにちは、富士榮です。

    今回もMountainViewのGoogleのオフィスで開催されてたOpenID Foundation Workshopに参加しています。いつもの通りInternet Identity Workshop(IIW)の前日イベントとして開催されています。

    相変わらず持って帰りたくなるGoogle自転車です。運用を見ていると、各所に乗り捨てられた自転車をトラックで集めてオフィス単位で分配する、というアナログな形で提供されているようです。さすがに場所のトラッキングなどはされているとは思いますが。


    全体アジェンダはこちらです。




    Opening - Gail Hodges, Nat Sakimura

    直前にマンチェスターであったISOのミーティングでもAI、量子コンピューター、メタバースなどのキーワードとアイデンティティやプライバシーに関連するトピックで話があった、とのコメントが崎村さんからありました。

    eKYC & IDA Working Group - Mark Haine

    まずはMarkからeKYC & Identity Assurance WGの進捗について。

    Implementer's Draft 4から4つのスペックに分割しました。
    そして、まさに今ファイナライズに向けたレビューが進行中です。
    対象は下記の通り。
    • OpenID Connect for Identity Assurance 1.0
    • OpenID Identity Assurance schema definition 1.0 draft
    • OpenID Connect for Identity Assurance Claims Registration 1.0

    まずはIDAのファイナライズからですね。
    個人的な本命でもあるAuthorityのDraftも控えているので引き続き進めていきたいですね。


    デジタル庁とのコラボレーションについても触れられました。まさにIDAの実装が進もうとしている初期のインスタンスとして日本が貢献できるのは素晴らしいことだと思います。
    先週のISOミーティングでもAge Assurance(ISO 27566)とIDA仕様の連携についてディスカッションがあったことも報告されました。この辺りは選択的開示の文脈でVCへの適用などもされてくると思いますので要注目ですね。(21歳以上かどうかのみを開示する、など)

    AuthZEN Work Group Update - David Brossard, Omri Gazitt



    前回の日本でのWorkshopでも紹介しましたが、新しいワーキンググループですね。
    このワーキンググループのモチベーションとしてOWASPのトップ10 issueでもあるアクセスコントロールの問題やAPIセキュリティの問題へ対応していくことが重要、ということです。

    成果物として、認可パターン、ユースケース、コミュニケーションパターン、インテグレーションパターンをまとめたものや、認可リクエスト認可決定を行うためにPDP、PEPの間の標準化されたAPIの定義、そしてPAPからPDPへ認可ポリシーとデータを連携するためのAPIの定義が挙げられています。



    Interopシナリオの定義など、精力的に活動が進んでいるようですね。
    参考)Interop website

    SalesforceやServiceNowなどを含むSaaSアプリでも認可を外部化して、アクセスコントロールが適切に行えるようになると素晴らしいですね。WGでは今はアプリ単位で個別に制御をしないといけないところを、外部化することで企業や組織が権限を集中管理できるようになる将来を夢見ているということです。 

    OpenID Connect Work Group - Michael B. Jones


    次はOpenID Connect Working Groupです。
    歴史的にOpenID Connectプロトコルを定義してきていますが、その中からIDAやVC関連のプロトコルなど独立した仕様としてWG化したものを産んできました。

    昨年10月以降のUpdateで一番大きかったのはOpenID for Verifiable Credential IssuanceのImplementer's draft 1が4月に出たことですかね。あとはOpenID Federationの実環境へのデプロイがイタリアやオーストラリア、スウェーデンでも進んでいる、というのも興味深いですね。

    ISOの番号がちゃんとOpenID Connect関連の仕様にアサインされたのも非常に大きな進捗です。こういうデジュールに認められることはWTO的にも非常に重要です。

    今後のロードマップとして今年の終わりまでにFederationの仕様の最終化をしていくという野心的な試みも示されました。

    あとはなんといってもOpenID Summit Tokyoから続く10周年イベントのシリーズは今後もIdentiverseやEICでも続きます。成功の秘訣はなんといっても「Keep simple things simple」ですね。そして相互運用テストなどを含めエコシステムを生成するための営みも非常に重要なパートでした。


    FAPI Work Group Update - Nat Sakimura

    次はFAPIに関して崎村さんからです。

    すでにFinancial-gradeを超えてGeneral Purposeな高セキュリティなプロファイルになってきています。これまでIETFライクに書かれてきたスペックをISOにも容易に持っていけるように書いてい拘置しているのはConnect WGでもあったように世界でのアドプションには必要な取り組みですね。

    関連する仕様拡張も進んでいます。

    他にもホワイトペーパーやFormal Analysisなども進んでいます。

    仕様のファイナライズに向けて精力的に活動も続きます。だいぶ新しいIssueも減ってきたので最終化に向かえそう、ということです。


    MODRNA Work Group - Bjorn Hjelm

    次はMODRNAです。

    モバイルオペレーターにおいてMNOがIdentity Providerになることを想定したスタンダード開発のために発足したワーキンググループです。今ではFAPIでも使われているCIBAは元々はこのワーキンググループを中心に開発された仕様ですね。

    新しい動きとしては、CIBA ExtensionやRCS Verification Authority API向けのプロファイル作成などもありますし、IDAワーキンググループと共同で動いているCAMARA ProjectのIdentity and Consent Management SPとKnow Your Customer SPに関するリエゾン合意なども特筆すべきアクティビティです。日本ではKDDIさん中心に活動が進んでいますね。
    他にもGSMAやETSIとのリエゾンも進んでいます。

    今後のロードマップはこちらです。

    なお、こちらには書かれていませんが、ISOのPASと同じくITUとの連携の取り組みも進めようとしているようです。

    Digital Credentials Protocols (DCP) Work Group Update - Kristina Yasuda, Joseph Heenan

    次はKristinaとJosephによるDCPワーキンググループです。

    Josephが共同議長になったのが大きなニュースですね。
    あと、Connect WGでも話がありましたがOpenID for Verifiable Credential IssuanceのImplementer's draft 1が出たのは大きいです。また、日本でもいくつかの事業者が協力したOpenID for Verifiable Presentationsのコンフォーマンステストについても大きな進捗がありました。

    EUのLSPでは100以上の事業者がテストに参加しているのは素晴らしいですね。

    すでに次のステップに向けた仕様開発も進んでいて、どんどんアップデートされていきますのでついていくのが大変です。。。その中でも特にWalletプロバイダになる事業者の方々はカスタムURLスキーム問題に対応するためのブラウザAPIに関するW3Cとのディスカッションは追いかけていかないといけませんね。あとは先日書いた通り、Presentation Exchange 2.1も出てきていますのでQuery Languageも注目です。

    金曜日にDCPワーキンググループのF2Fも予定されているので、その中でW3Cとのリエゾンについても深掘りされていくことになりそうです。

    Shared Signals Work Group Update - Tim Cappali

    次はShared Signalです。Tim、Oktaに行ったんですね。。。


    まずはそもそものSSFがやりたいことの説明です。ログインの時だけ認証するのじゃ足りないよね、って話です。ログイン後も振る舞いを見ていくことでセキュアなアクセスを実現していくことができる、というわけです。

    SSFではSETなどIETFのスタンダードを使いつつCAEPなどのプロファイルを策定していっています。

    SSFも新しい共同議長を迎えています。事業者が入っているのは仕様の実効性の面で非常に重要なことだと思います。

    IIW、Identiverse、EICでもセッションが予定されており、活発に活動しています。また、SSFの相互運用性のプロファイルも作成されています。

    先日のガートナーのIAMサミットで相互運用性イベントをやったそうです。特にSSFでは複数のIdP事業者が連携することになるのでIDaaS事業者の間での相互運用性の担保が非常に重要です。

    結果もいい感じですね。楽しそうです。



    OIDF Certification Program Update + Roadmap - Joseph Heenan

    次はCertificationプログラムのUpdateです。
    EUでのLSPに多くの事業者が参加したり、IDAのテストも開発されていたり、とこちらも多くの進捗が報告されています。
    OpenID Federationのテストについてもファンドがされたので開発が始まりそうですね。

    認定プログラムの特徴の一つは特にFAPIに表れているように特定の国のプロファイル(ブラジルのオープンバンキングなど)を対象としたテストも存在しているところですね。各国でプロファイルを定義して、技術面での認定をOIDFが実施する、というエコシステムになっているわけです。

    Death & the Digital Estate Community Group - Dean Saxe

    興味深いトピックです。死後のデジタルアカウントや資産をどうやって扱うか?についてフォーカスした営みです。

    アイデンティティシステムにおいてライフサイクル設計をすることは重要ですが、「死」というステートは滅多にフォーカスされることはありません。SNS上のデータをはじめとするデジタル資産を廃棄する仕組みが用意されていることはほとんどありません。権限委譲やアカウントの削除、など必要になりそうなものは多くありそうです。デジタル遺言書なども一部検討は始まっていますね。

    この活動では、新しいOIDFのコミュニティグループ、長期的にはワーキンググループの設立を目指しています。

    Q2をターゲットに活動するので手伝ってね、とのこと。これはカルチャーごとに考え方も変わりそうですし、アジア圏からのコントリビューションができるといいですね。


    Sustainable & Interoperable Digital Identity(SIDI) Hub Update - Gail Hodges

    次はSIDI Hubに関するUpdateです。

    SIDI Hubの2024のストラテジーが出てます、って話です。当ブログでも取り上げましたね。



    今年はイベントてんこ盛りです。目下調整中ですが、10/25に東京でも開催される予定です!(私が今回IIWに来た理由の一つでもあります)

    Listening Session: Post-Quantum Computing & Identity - Gail Hodges, Nancy Cam-Winget, John Bradley, Rick Byers, Andrea D'Intino

    ポストクォンタムとアイデンティティのパネルディスカッションです。
    まずはforkbombのAndreaからです。EUのファンドを受けてOSSの量子をやっている人たちです。

    W3C-VCにQuantum-proofを使おうって話です。ECDSAのさらに次を、ということですね。

    インプリもしているみたいです。




    こんな感じでproofを作っているみたいです。

    サンプルやデモもあるみたいです。


    ということでディスカッションです。

    PQの暗号アルゴリズムの強固性の前に、鍵管理・ローテーション・交換の問題やサイドチャネル耐性問題など解決する必要がある課題がいっぱいあるよねぇ。。という話とか、プロトコル自体がTLSに依存している状態なのが現状で、場合によってTLSを信頼するけど、場合によってPQが必要っていう矛盾した議論が起きそう、、みたいなコメントがありました。まぁ、エコシステムが複雑化してしまっている環境下において特定の技術要素だけで全体を解決するのは不可能、ってことかと。
    他にも現在の仕組みからPQへのトランジションをどのように安全に行っていくのか?などのコメントもありましたが、こちらも今後のトピックになってくるんだと思います。

    全体として、まだOIDFの枠の中で何かアクションを起こしていくのは早いのでは?という雰囲気でしたが、鍵管理などの運用問題についてはなんらかの手を打っていくのが良いかもしれません。

    Listening Session: AI & Identity. What are your concerns? What is OIDF’s role? - Gail Hodges, Nancy Cam-Winget, Kaelig Deloumeau-Prigent, Mike Kiser, Geraint Rogers

    引き続きパネルディスカッションです。こちらはAIとアイデンティティに関する議論です。

    まず最初にドイツテレコムが公開しているこちらのYoutube Videoを見ました。

    ソーシャルメディア上に公開される子供の写真をAIをベースに年齢を進め、自由に喋らせる、なんてことが誰にでもできてしまう時代が来てしまっている。Virtualプライバシーをどうやって守るのか?は誰もが直面する問題になってきている一方でみんなが無邪気だってことですね。これは由々しき問題です。

    同時にLLMのプロンプトでJSでOIDCを実装するには?って聞いてみると、簡単に教えてくれるけどテストや認定プログラムの話がでない、などカジュアル化が進みすぎちゃっている問題もありますね。


    OSS化が進み、モデルが小さくなり、必要なコンピュートリソースが少なくて済むようになり、モバイルデバイス上でさえAIが動くようになり、実際モデルナがワクチン開発にAIを活用したのと同じことがハッカーによっても手軽に実行できるようになった際のバイメトリクスはどうなるんだろうか?この辺りはすぐにアイデンティティ業界にとっても大きな課題になってくると思います。

    ということで充実したワークショップでした!





    IIW#38 Day1クィックレビュー

    $
    0
    0

    こんにちは、富士榮です。

    ということで初日が終わったIIW(Internet Identity Workshop)ですが自分メモとして記録をしておきたいと思います。

    といってもアンカンファレンスなのでゆるーく話を聞いていた部分も多く、特に印象に残っているセッションについてのみ記録しています。


    いつものアジェンダ作成の会です。



    今回私が参加したのは、以下のセッションです。

    1. DCC Update - Dmitri Zagidulin
    2. Should Proof of Humanity apply to My Personal AI? - Adrian
    3. SD-JWT(SD-JWT VC & SD-JWT VDM) - Kristina Yasuda, Oliver Terbu
    4. Decentralized Storage & Bring your own identity - Aaron
    5. OID4VCI Events - Oliver Terbu

    どれも面白かったのですが、1番目のDCCの話と5番目のOID4VCI Eventsの話をメモしておきます。

    DCC Update

    ずっと追いかけているMITが中心に進めているDCC(Digital Credential Consortium)です。これまでもIIWやその他のミーティングで色々と情報交換はしてきたのですが、ここにきてかなりの進捗があったように感じます。


    昨年3度目のPlugFestをJFFとジョイントで実施した、ということで実装が揃ってきているのが素晴らしいですね。

    DCC自体もOSSでIssuerおよびWalletなどのモジュールを公開しています。

    https://github.com/digitalcredentials


    Issuerの管理ツールも公開されていて、dockerイメージなので割と簡単にセットアップできます。私も入れてみました。(細かいところは追々)


    Walletについてもソースコードも公開されていますし、ストアに公開もされています。

    (ちょっとカスタムURLスキームが独自過ぎるのが微妙ですが)

    こう言うベースがあるとフィードバックのループも回ると思いますので成長できそうです。みなさんも触ってみてフィードバックしましょう。


    OID4VCI Events

    Oliverのセッションです。

    OID4VCIでWalletに発行されたVCに関してShared Signalを使ってイベントを送信することでライフサイクル管理を厳格化しましょう、というシナリオの提案です。

    ユースケースとしては

    • Notify the wallet in case the credential got revoked before end of TTL window
    • Notify the wallet in case a new credential type can be requested
    • Notify the wallet thee data for one credential got updated and a new credential with the updated data is available

    が挙げられていました。


    ちょっと光ってしまっていますがこんなことを考えているそうです。


    アイデアとしては結構面白かったのでうまく進むといいなぁ、と思います。

    現時点での私のコメントはVC発行のときに使うアクセストークンとSSFの登録を行う際に使うアクセストークンはぜひスコープを分けてもらい、Issuanceの際に同じスクリーンで同意ができるようにできるといいと思います。発行はOAuthの世界で同意、プッシュ通知はモバイルアプリの世界で通知(まぁ、これはどっちにしろいるわけですが)という形でバラバラになるよりも、発行はOKだけど通知は嫌、みたいなシナリオにも最初の段階で対応できるようなUIが実現できる方が良いなぁ、と思いました。


    ということでまた明日!


    IIW #38 Day2クイックレビュー

    $
    0
    0
    こんにちは、富士榮です。

    昨日に引き続きIIW(Internet Identity Workshop)の記録です。

    今日も主要なセッションについてメモしていきたいと思います。
    印象に残ったのが以下のセッションです。
    • Cross Platform Demo of Digital Credential API - Eric@Apple, etc.
    • OpenID for VP + OpenID for VP over Browser API - Kristina, Joseph, Torsten
    • Demo hour(ブータン、台湾の展示)

    早速みていきます。
    まずはApple/Googleからの発表です。

    Cross Platform Demo of Digital Credential API - Eric@Apple, etc.

    要するに、Credential APIを使ってWalletとの間のインタラクションを簡素化しましょう、という話です。
    従来だとIssuance requestやPresentation requestをCross deviceだとQRコード、Same deviceだとカスタムURLスキームで、という形でブラウザとWalletとの間でやり取りをしていましたが、これまでにも触れたカスタムURLスキームの後勝ち問題など、OSの仕組み上どうしようもない課題が存在していていました。
    しかし、よく考えてみると同一デバイスならブラウザから直接呼び出し、別デバイスならQRコードを表示する、というUXは他でもみたことがありますよね?そう、パスキーです。パスキーでは以前解説したとおりcredential.get()などのブラウザAPIを使って認証機能を呼び出していました。
    このアイデアはOpenID for Verifiable Credentials関連の仕様においても同じ仕組みを使えるようにブラウザAPIの拡張を行うことはできないか?という話で、今回AppleとGoogleがそれぞれのデバイスで実装したデモを披露してくれました。

    こんな感じでidentityDocumentのrequest/responseをブラウザAPIを使って実現します。


    実際に動くデモがiOS/Androidの両方で披露されました。

    OpenID for VP + OpenID for VP over Browser API - Kristina, Joseph, Torsten

    前のセッションに引き続きプロトコルの面からの詳細解説です。

    先に記載した通り、VerifierでPresentation requestを行うところでブラウザAPIを使うことで、現在VerifierがQRコードを自前で生成しているがこれをより安全に生成することはできないか?そして、Crossデバイスの際にパスキーでQRコードを出す仕組みをそのまま使うことでカスタムURLスキームを使わずに済むようにできないか?またフィッシングレジスタントという意味でもこの辺りはパスキーと同様の仕組みにするのがリーズナブルではないか?などモチベーションが紹介されました。



    呼び出し方については
    navigator.identity.get({
      digital: {
        prividers: [{
          protocol: "urn:openid.net:oid4vp"
          request: JSON.stringfy({
           ※ここにOID4VPリクエストを入れる
       ※ただし、Client_id_scheme : "web-origin"を追加する
    というイメージでAPIを実行するようです。

    Demo Hour①(ブータンの国民ID)

    少しセッションとは毛色が異なりますが、ブータンの国民ID、Walletの展示がありました。


    オンボーディング時は軍の方が各家庭を回って本人確認〜登録を勧めたそうです。スマートフォンの配布もこの際に行ったそうです。


    なお、インドと同様に各国民の生体情報(実際は特徴点情報)が国側に登録されているのでアクティベーションにいは生体情報を使います。

    ざっくりメモです。
    • インドの会社が作っている
    • Hyperledger Ariesベース
    • anonCredを使っている
    • オンボーディングの際は軍が一人一人を訪ねて立ち上げをサポート
    • スマホも配った
    • ブートストラップする際は生体認証(そもそも国側に顔の情報が登録済み)
    • 顔認証が通るとFundamental Credentialが落ちてくる
    • それをベースに自己発行のクレデンシャの作成などもできる
    • 民間で使う場合、例えば銀行口座を解説する場合などはサインアップ時にVCを提示してアカウントを作る
    • アカウントが作られるとVCとしてWalletに取り込まれる
    • そのVCを使ってオンラインバンクへのログインができる
    • モチベーションとしては高地に住んでいる人が対面銀行に来るとなると標高差年全mの移動が必要となるのでデジタル化は必須だった
    • ちなみにインドでも同じスタックを使っているので、インドでもこのWalletは使える
    • 実際にオフィスの扉の開錠に使っている

    Demo Hour②(台湾のデジタルIDウォレット)

    ちょうどオードリー・タン大臣の退任が伝えられたばかりですが、台湾のデジタルIDウォレットの展示がありました。

    2027年の向けてオープンソースで開発を進めているそうです。
    また、トラストリストを持つことで安心して使えるようにしているのも特徴ですね。

    キャラクターグッズ?をもらいました。

    以下メモです。
    • 細かいプロトコルやクレデンシャルフォーマットは動くので抽象化した実装となっている
    • OSSで公開してブラッシュアップをしていくモデルだが、政府が7ミリオンドルくらいを毎年予算計上している
    • モチベーションとしては地政学リスクを考えて、分権型としている(中央集権だと中国に乗っ取られたら終わる)
    • トラストリストを作り、利用できる事業者やサービスを絞ることで利用者に安心を与えている
    • オンボード時はtwFIDOとの連携している

    こう言う形で実装を早い段階で展示して多くの人の意見をもらえるようにしていけるといいですね。
    明日は最終日です。また記録していきたいと思います。


    IIW #38 Day3クイックレビュー

    $
    0
    0

    こんにちは、富士榮です。

    いよいよ最終日でした。

    一昨日昨日に引き続きIIW(Internet Identity Workshop)のクイックレビューです。


    本日は、

    • OID4VP Suggestions for query syntax(P.E.) simplification - Tobias, Kristina, Oliver
    • OID4VC as Framework vs Profiles - Kristina
    • Verifiable Credentials with BBS+ and zk-SNARKs for Predicate Proofs - Dan Yamamoto
    • Learning Record - Mehesh Balan

    あたりを記録しておきたいと思います。


    OID4VP Suggestions for query syntax(P.E.) simplification - Tobias, Kristina, Oliver

    現在OpenID for Verifiable Presentations(OID4VP)はPresentation Exchange 2.0.0(PE)を使っているがシンプルにできないか?という話です。現在、要件をDCPWGで洗い出しているそうです。
    例えば、
    • JWTでCBORでも使えるようにしたい
    • SDにも対応できるようにしたい
    • ネスト構造にも対応できるようにしたい
    などがテーマのようです。

    うまく、OID4VPをプロトコル、PEをクエリ言語としてモジュラー型にできるか、という議論もあります。方向性としてはPEをシンプル化してBreaking changeを極小化する形に落ち着いてくると思われます。
    具体的にはinput_descriptorsの下にformat要素を作り、例えばmDocならdoctypeとしてmDL、claimsにnamespaceやdata_element_idを指定する、という形で考えているようです。


    OID4VC as Framework vs Profiles - Kristina

    引き続きKristinaさんのセッションです。

    相互運用性を担保するために必要なこととしてあげられる、
    • Definition of "mandatory to implement" element of the protocols
    • Wallet invocation mechanism. Custom url scheme, etc
    • Verifierにおける認証メカニズム
    • Walletのクレデンシャルフォーマット
      • issuerの識別とキー解決
      • Holder key binding
    • 暗号アルゴリズム
    をプロファイルとして定義していこう、という話ですね。
    これはOAuthでも行われていることでRFC6749はFrameworkでFAPIなどはプロファイル、という言い方をします。
    しかし、FAPIではブラジルやオーストラリアのオープンバンキング向け、など各国向けのプロファイルが存在している状態になっています。今回のOpenID for Verifiable Credentialsはどうしていくのか?は考えないといけないところだと思います。
    現在、HAIP(High Assurance Interoperable Profile)が定義され、EUではこのプロファイルを使うことになっていますが、これが全世界的に受け入れられるプロファイルとなるのか、もう少しコアプロファイルを削り出して個別の事情を含め柔軟に受け入れられるようになるか、は今後のデザイン次第だと思います。

    参考までに、HAIPでは
    • Protocol profile
      • SIOP,OID4VP,OID4VCI
    • Credential profile: SD-JWT VC
      • SD-JWT VC
      • JWT/CWT Statuslist
    • Wallet Attestation Scheme
      • Attestation based client authentication
    • Basic choices
      • Custom scheme
      • Issuer key resolution
    • Crypto suite
    あたりが決められています。

    Verifiable Credentials with BBS+ and zk-SNARKs for Predicate Proofs - Dan Yamamoto

    次はIIJの山本さんのセッションです。

    これまでも毎年Updateされてきているzkp playgroundを使って動きを見ながらこれまでの研究成果を発表してくれています。
    参考)

    今回はこれまでBBS+で実装してきたSelective Disclosureに加えてzk-SNARKを使ったPredicateへの対応です。
    具体的に言うと、単純に名前や生年月日を開示する・しないを選択できる選択的開示に加えて、21歳以上かどうか?などと言った判定結果のみを開示する、ということにも対応した、という話です。

    具体的には、RDFのブランクを示す、”_;"から始まる文字列で対象となる値を置き換えます。
    例)birthDate: "_:HIDDEN_DATETIME"
    この状態でpredicateタイプとしてprivate<publicといった演算子を選択し、
    • privateに先ほど指定した_:HIDDEN_DATETIMEを、
    • publicに比較対象となる日付、例えば"2003-04-018T23:59:59Z"を
    設定します。

    こうすると実際の値が隠されたプロパティがpublicに指定した値よりも大きいのか小さいのか、ということがクレデンシャル内にセットされるためVerifierは判別ができる、という仕掛けです。

    また、この結果のVerifiable Presentationを検証できるChrome Extensionを用意しており、例えばデモで見せてくれたのはBlueSkyに当該のVPを配置したストレージ(デモではgithub)のURLを投稿、このリンクの値を検証することで本当にこのアカウントの持ち主は21歳以上なのかどうかを検証ができる、というシナリオでした。

    こう言う形で動いているものを見ながら議論ができると盛り上がっていいですね。

    Learning Record - Mehesh Balan

    最後はMeheshさんの学修歴クレデンシャルです。アリゾナ州立大学の学位などをVCとして発行する、というシナリオで実装をしているそうですが、実際の社会実装として適用していくためにはどうしていくのがいいのか?というどこかで聞いたような話でお悩み相談でした。
    (スピーカーと私を含めて全部で3人のセッションだったので本当にお悩み相談っぽかったです)

    ちょうどアリゾナ州にはTSMCの工場ができていたり、と半導体が盛り上がっているので学生を送り込みたいところなのですが、効率的にスキル証明をすることができれば、という話です。これもどこかで聞いた話だなぁ、と。

    具体的なお悩みポイントは、
    • Issuerのトラストをどのようにして検証するのか
    • どうやってVerifier(例えばTSMC)に受け入れてもらうか
    です。

    まず、トラストの話はX.509のルートを辿っていく、という話も出てきましたが、技術以外にトラストフレームワークをどう捉えるのかも総合して考えないとダメだよね、という話をしました。米国の大学ではinCommonがあるのでそのSPとしてTSMCを構成すればそもそもVCじゃなくてもいいのでは?という話もありますが、卒業生や他の大学の学生などトラストフレームワークの外のエンティティをどうやって担保するのか?という話なども議論の種でした。

    Verifierとの調整の話は典型的な卵・鶏の話なので、まずはアカデミアの世界でちゃんとグローバル標準を作って、より多くの大学が同じタイプのクレデンシャルを発行できる状態を作って数で勝負していなかないとダメ、という話をしました。この辺りは某QRコード決済を普及された事業者がやっていたような力技もどこかで必要になるでしょうし、政府のサポートも重要なファクターとなると思われます。

    また半年後、もしくは1年後に彼とは情報交換をして進捗を確認し合っていけると良いと思いました。



    ということで3日間のIIWはおしまいです。
    ここに書いた話以外にもサイドで個別に議論をできたことも多く、結果的に実りのある3日間でした。また次回の秋もしくは1年後に参加して進捗を見ていきたいと思います。

    OpenID Technight #21を開催します。今回はShared SignalとIIWの振り返りです

    $
    0
    0
    こんにちは、富士榮です。

    半年ぶりくらいになるでしょうか?OpenID Technight #21を開催します。
    今回は対面+オンラインのハイブリッド開催です。

    気になるテーマはマニアックに「Shared Signal Framework」です。まさにID基盤を裏から支える縁の下の力持ちのフレームワークで、主にリスクイベントやアイデンティティ・ライフサイクル上で発生する様々なイベントを裏側でIdP同士やIdPからクライアントへ伝達するためのシグナリングのための仕組みです。

    また、時期的にもInternet Identity Workshop(IIW)の前後でありましたOpenID Foundation Workshopを含むIIWでの最新情報などについても、OpenIDファウンデーションジャパンの最新動向と合わせてお話できると思います。

    ということでぜひ重し込みください。

    お会いできるのを楽しみにしています。

    Interopカンファレンスは今年もトラストで!

    $
    0
    0
    こんにちは、富士榮です。

    昨年はパネリストでおよびいただいておりましたが、今年はプログラム委員を拝命いたしましたInteropカンファレンスがいよいよ6月に迫ってきています。申し込みも開始されたようなのでぜひお越しください。


    さて、私の担当プログラムは例によってトラストが中心です。

    1. Trusted Web(1) デジタル空間におけるトラストをいかにして実現するか?
    • こちらはクロサカさん、鈴木先生と一緒にTrusted Webの進捗を語りたいと思います。ちょうどホワイトペーパーもv3.0が昨年度発行され、いろいろな取り組みが表に出てき始めていますが、まだEUのように社会実装にまでは至ってはいません。この辺りについての観測と今後の展望についてお話しできるといいのではないかと思います。
    • https://f2ff.jp/introduction/8830?event_id=conf-2024-06
  • Trusted Web(2) 実社会での本格利用に向けて動き始めた分散型IDとデジタルIDウォレット
    • こちらはDataSignの太田さん、DNPの岡本さん、高市さんをお招きして実際に開発をされている方々のご意見を伺ってみたいと思います。両社ともTrusted Webの実証事業者としてウォレットや分散型IDに関する基盤開発に関わってきていらっしゃる事業者の方なので、開発の実際や今後の展開における課題などを聞いていきたいと思います。
    • https://f2ff.jp/introduction/8831?event_id=conf-2024-06



    もちろん、これ以外にも数多くの興味深いセッションがありますので、ぜひ参加登録をしてください。

    自民党web3PTの2024年版ホワイトペーパーのテーマの一つはDID/VC

    $
    0
    0

    こんにちは、富士榮です。

    先日リリースされた自民党のweb3PT(プロジェクトチーム)のホワイトペーパーのテーマの一つとしてDID/VCが取り上げられていますね。ブロックチェーン、DAO一筋だったころに比べると社会実装に向けて現実的な路線も取り入れられてきていて成熟してきた感があります。


    新たなテクノロジーが社会基盤となる時代へweb3PTが「ホワイトペーパー2024」を策定

    https://www.jimin.jp/news/information/208018.html


    発行されたホワイトペーパーの要旨にはこんな感じで「VC及びDIDの利活用促進、DIWに関する検討」がテーマとして記載されています。実はこのDID→VCではなく「VC及びDID」となっているところが個人的には注目です。これまでのweb3ではDIDが全面に出てきていましたが、ようやく本質はVCだということが理解されてきたようです。事務局のみなさん本当にお疲れ様です。



    ちなみに、平井卓也さんのInstagramに会合の様子が掲載されています。この会は私もお邪魔してVCとブロックチェーンの関係性の話を少しお話してきました。(あんなに細かい話をして良かったのかどうかは置いておいて)


    ちなみにホワイトペーパーは平将明さんのページにダウンロードリンクが紹介されています。

    https://www.taira-m.jp/2024/04/web3-3.html


    Digital Credential Consortiumが公開しているVerifiable Credentials関連サービスを試す

    $
    0
    0
    こんにちは、富士榮です。

    Digital Credential Consortiumが公開しているOSSのVerifiable CredentialsのIssuer/Walletを試してみました。
    Adminダッシュボード
    Learner Wallet

    何をするツールなのか、というと学修歴(に限りませんが)をVerifiable Credentialとして発行する管理ツール(ダッシュボード)とそれを受け取るための学習者向けのWalletの組み合わせになっており、管理者が定義したVCを学習者に対して発行することができます。

    導入方法は非常に簡単で、
    に書かれている通り、dockerイメージを落としてきて実行するだけです。

    ただ、本ツールは基本的にメールでクレデンシャル発行要求を飛ばすところから始まる前提となっているので(要所要所にOpenBadge系の匂いがします)、メールサーバの設定をしてあげる必要があります。
    そのためには、手順にある
    curl https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml | docker compose -f - up

    ではなく、 

    https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml

    をダウンロードしてきてメールサーバに関する記述を変更した上で、docker-compose.ymlにリネーム、docker-compose -up -dをする方がベターです。

    変更対象は

          - SMTP_HOST=sandbox.smtp.mailtrap.io

          - SMTP_USER=myusername

          - SMTP_PASS=mypassword

    の3行です。私はテスト用にmailtrapを使ったので必要なSMTPホストやユーザID、パスワードはmailtrapのサンドボックスの値を使いました。

    これでdockerイメージから起動すると、http://localhost:3000で管理画面へアクセスできます。初回は管理ユーザを作成するところから始まります。
    最初の画面です。
    まだ何もありません。
    使い方としては、まず最初にCredential Templatesから発行するVCの定義を行います。
    タイトルやテンプレートとなるJSONを記載してきます。
    ちなみに
    にサンプルのJSONテンプレートがあるのでそのまま使いました。
    定義ができました。
    次がEmail Templatesです。先ほど書いた通り、メールでVC発行をユーザへ通知する仕組みなのでそのメールの本文を定義します。
    これも先ほどのドキュメントにテンプレートのサンプルがあるので、そのまま設定します。
    これで設定はおしまいです。
    非常に簡単です。

    あとは、実際にVCを発行することになりますが、最初のIssuance OverviewのページからUpload and Prepare BatchをクリックしてVCの発行を行います。
    基本は先ほどのCredential Templatesの定義とEmail Templatesの定義を指定し、CSVファイルに記載した宛先に対してメールを飛ばす仕組みになっています。

    必要なフィールドを入れたCSVファイルを用意してアップロードします。
    準備ができるとこんな感じで送信確認を行います。

    実際に送信するとメールが届くのでメールのリンクをクリックします。
    先述の通りmailtrapを使っているのでサンドボックスからメールの確認ができます。
    このリンクを実行するとVC発行のQRコードが出てきます。

    これを先ほどのLearner Walletで読み込みます。
    すると、、、、エラーがでます。



    作者のDmitriに聞いてみましたが、どうやらバグっぽいので治るのを待ちましょう。
    しばらくしたらまた試してみたいと思います。

    しかし、こう言うツールがOSSで出てくるのは非常にいいですね。うまくコントリビューションしていければと思います。





    NIST SP800-63Bへの同期可能な認証器に関する補足文書がリリースされています

    $
    0
    0

    こんにちは、富士榮です。

    パスキーを使う際に、AppleやGoogle、Microsoftなどのクラウドプラットフォームを通じたデバイス間で鍵の同期を行うSyned Passkeysをどう扱うか?、つまりそもそもFIDO認証の良いところはデバイスとの紐付けが強固であることだったはず、一方で鍵のリカバリが認証強度の弱点となりクレデンシャルの盗難や不正利用のきっかけになってしまう、その意味で鍵の同期は必要なのである、といった論争もひと段落してきたわけですが、その意味でパスキーを念頭においた各種ガイドラインについても更新される時期が来ているのかもしれません。

    今回、NISTからSP800-63Bに関する同期可能な認証器に関する補足文書が公開されています。


    アナウンス原文はこちら)

    https://www.nist.gov/blogs/cybersecurity-insights/giving-nist-digital-identity-guidelines-boost-supplement-incorporating

     公開された文書はこちら)

    https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf

     

    アナウンスに概要が記載されているので紹介しておきます。(Google Webページ翻訳)

    補足文書とは何か?

    補足は、既存の NIST Special Publication (SP) を強化、拡張、または詳しく説明することを目的とした特定の文書タイプです。これにより、SP 全体を更新するプロセスを経ることなく、対象を絞った更新や変更が可能になります。これらは、NIST がテクノロジーとリスク環境の変化により迅速に適応するためのメカニズムを提供します (たとえば、同期可能な認証システムのような新しい認証システム タイプの要件を提供します)。 

    同期可能な認証器とはなにか?

    同期可能な認証システムは、秘密キーを複製して認証システムとは別に保存して、異なるデバイス間でのその鍵の使用 (同期など) をサポートできる暗号化認証システムです。実際には、これらは通常、FIDO Allianceによって「パスキー」と呼ばれるもので、Client-to-Authenticator Protocol や World Wide Web Consortium (W3C) の Web Authentication (WebAuthn) などの複数の標準およびプロトコルを利用します。 

    正しく実装されると、シンプルなリカバリ、クロスデバイスのサポート、消費者に優しいプラットフォーム認証サポート (ネイティブ生体認証など) など、多くの利点を備えたフィッシング耐性のある認証システムが提供されます。このような認証システムは、デジタル ID ガイドラインのコンテキストでは非準拠とみなされ、補足では、認証保証レベル 2 (AAL2) での使用を許可するための追加の要件と考慮事項が規定されています。 

    ガイドライン(SP800-63-3)が発行されてからの世の中の変化は?

    多くのことが変わりました。ガイドラインが最初に開発および発行された時点では、同期可能な認証システムをサポートするための標準と仕様は開発されていませんでした。それ以来、標準は成熟し、ほとんどの主要な消費者プラットフォームが同期可能な認証システムのサポートを導入しました。  FIDO Alliance はこれまでのところ、80 億を超えるユーザー アカウントが認証にパスキーを使用するオプションを備えていると推定しています。まだどこにでも普及しているわけではありませんが、日に日に一般的になってきています。 

    鍵の複製に関するリスクは?

    そう、リスクは常に存在するのです。補足の要件は、キーの保存、送信、保護の方法を含め、これらの要件にできるだけ多く対処することを目的としています。同期可能なオーセンティケーターには特有のリスクが伴います。特に、一部の技術実装におけるユーザーが自分の認証キーを他の個人と共有する機能です。認証子を共有する機能は同期可能なキーに固有のものではなく、ほぼすべての AAL2 認証子を共有できます。しかし、長年のセキュリティ ポリシーに反して、一部の実装では、多くの消費者シナリオでパスワード共有の安全な代替手段として同期可能な認証子の共有を推進しています。 

    すべてのインスタンスと同様に、組織は、提供するあらゆるタイプの認証システムを評価し、実装する前にそれに伴うメリットとリスクを比較検討する必要があります。同期可能なオーセンティケータは、すべてのアプリケーションやサービスに適しているわけではありませんが、エンドユーザーと信頼当事者の両方に多くのメリットをもたらす、新たな AAL2認証器オプションとなります。

    パブリックコメント期間は設けられるのか?

    この更新文書には適していません 。 SP 800-63-4 に関する最初のパブリック コメント期間からのフィードバックがこの補足資料に組み込まれました。同期可能な認証システムと補足の全体的な内容に関する追加のコメントは、リビジョン 4 の今後の第 2 回パブリック コメント期間を通じて提出できます。これは今年後半に行われる予定です。 

    SP800-63-4を待たないのか?

    上で述べたように、デジタル ID ガイドラインの規範文に厳密に従っている政府機関は、同期可能な認証システムを使用することを許可されません。この補足では、連邦ゼロトラスト戦略をサポートする強力で使いやすく、フィッシング耐性のある認証を提供する新しいセキュリティ技術の使用方法についての指示を提供することで、多くの政府機関の当面のニーズに対応しています。リビジョン 4 が完成すると、この補足は廃止されます。


    技術や状況は日々変わってきているので柔軟にガイドラインも対応していく必要がありますね。

    滅びてほしい認証系の実装の話

    $
    0
    0

    こんにちは、富士榮です。

    ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。



    考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。(実装ミスは問題外として)

    カテゴリ滅びてほしいもの実装側がやりたいこと利用者が感じること実際に起きていること代替手法
    認証CAPTCHAbot避けぐにゃぐにゃ文字が読めない
    バイクと自転車の違いとは?
    ユーザの離脱、カゴ落ちパスキーの利用
    新しいタイプのCAPTCHA(通常は画面に出ない)
    リスクベース認証との組み合わせによる抑制
    認証パスワード誰でも使える認証手段の用意忘れる。複雑なパスワードをそれぞれのサービス毎に管理するのは無理パスワードの使い回し。パスワード漏洩が他サービスへ迷惑をかける(逆もしかり)パスキーの利用
    認証パスワードマネージャが対応できないパスワードポリシー、input type要素の設定ミス。コピペができない、自分の設定したパスワードの確認ができない何も考えていない(単なる考慮不足)パスワードマネージャが使えないので自分でパスワード入力が必要で面倒くさい簡単なパスワードの指定パスワードマネージャを考慮した実装
    認証(届かない)OTP認証強化(所持認証)SMS受信できないSIMなんだけど
    なかなか届かない。すぐにログインしたいのに。
    ユーザの離脱、カゴ落ちパスキーの利用
    認証(音声通知のみの)OTP認証強化(所持認証)データSIMやiPadじゃ使えない
    面倒臭い
    ユーザの離脱、カゴ落ちパスキーの利用
    認証input typeがpasswordになっているOTP(毎回記憶を促される)何も考えていない(単なる考慮不足)面倒臭いパスワードマネージャが毎回更新の確認をしてくる適切な実装
    認証キャリア回線認証認証強化(所持認証)wifi切り替えが面倒(別デバイスで使えない)ユーザの離脱、カゴ落ちパスキーの利用
    認証ソフトウェアキーボードキーロガー対策面倒臭いユーザの離脱、カゴ落ちパスキーなど知識認証を使わせない仕組み
    (そもそもキー入力不要にする)
    認証定期的なパスワード更新パスワードが漏洩していても安心面倒。仕方ないので簡単なパスワードの末尾を1,2,3とインクリメントして使い回そう簡単なパスワードの指定複雑なパスワード要件の定義によるパスワードマネージャ利用の促進と併せて定期変更の無効化
    パスキーの利用
    認証乱数表認証強化(所持認証)どこいった?ユーザの離脱、カゴ落ちソフトウェア認証器、パスキーの利用
    認証第2パスワード認証強化(多段階)忘れる。意味は?問い合わせの増加、ユーザ離脱ソフトウェア認証器、パスキーの利用
    証明書オレオレ認証局のRoot CA入れろってやつ...w第三者に頼らずに信頼できる環境を作り上げたい(JPKI・・・)面倒くさい、やり方が複雑すぎるユーザの離脱、カゴ落ちブラウザベンダとの調整
    上位レイヤーでのトラスト確保
    リカバリ秘密の質問パスワード忘れへのヘルプデスク対応を減らしたいどの質問にどう回答したか忘れる
    出身地とかって他の人でも答えられるんじゃない?(全然秘密じゃない)
    アカウント乗っ取り同期可能パスキーの利用
    リカバリパスワードリマインドで平文パスワードが送られてくるパスワード忘れへのヘルプデスク対応を減らしたい不安。。ユーザの離脱、カゴ落ち同期可能パスキーの利用
    識別独自ID(メールアドレスじゃない)好きなIDの利用によるロイヤリティ忘れる
    好きなものが取れない
    変えられない?
    ユーザの離脱、カゴ落ちオートフィル
    変更可能なIDの利用
    本人確認eKYC(セルフィー+免許証の顔写真比較)本人確認うまくいかない券面偽造による不正登録ICチップの利用
    登録偽ソーシャルログイン(メアドのverifyやパスワード登録を求めてくるやつ)属性入力の簡素化による離脱防止
    認証手段は自前で用意することによるサポートの簡素化
    ソーシャルログインなのになぜパスワード登録が必要なのかわからないユーザの離脱、カゴ落ち属性登録と認証手段登録の分離(UX)
    認証手段としてパスキーをデフォルトにする
    決済カードのCVVを入力させる決済を確実に、素早く実行できるのでカゴ落ちが減る不安。。ユーザの離脱、カゴ落ち
    PCIDSSの取得が必須になりコストアップ
    3Dセキュアなどに任せてしまう


    他にもあればぜひご意見ください。



    CACTIの次世代クレデンシャルに関するレポート(1)

    $
    0
    0
    こんにちは、富士榮です。

    先日書いたInternet2のNext Generation Credential Working Groupのレポートについて見ていきます。

    オーサーはInternet2、デトロイト大学、イリノイ州立大学の方々が名を連ねています。
    CACTI Next-Generation Credentials Working Group自体のメンバーはかなり多岐に渡っていて、先ほどのオーサーが所属する大学やMITなどの大学群、Yubico(といってもJohn Bradleyですが)、日本からもNII、Wide Project、私もOpenIDファウンデーション・ジャパンの帽子で名前だけ載っています。
    (実態はほとんど貢献してません)

    早速見ていきましょう。

    まずは、エグゼクティブ・サマリです。

    2023 年 4 月、Internet2 の Trust and Identity Services 部門のアーキテクチャ ガバナンス グループである Internet2 Community Architecture for Trust and Identity (CACTI) は、研究と教育 (R&E) のアイデンティティとアクセスに関する世界的な参加を求めるオープンなワーキング グループを設立しました。 管理 (IAM) コミュニティ。R&E ミッションをサポートする新しいテクノロジーの採用の可能性を探ります。

    ちょうど、IIWのタイミングでInternet2のRoyさんとMITのDmitriさんと会話したところから私も参加することになりました。

    どんな目標だったのか、についてチャーターに記載されています。

    電子 ID の状況は、従来のフェデレーテッド Web シングル サインオン インフラストラクチャで使用されていた強力に集中化されたモデルから、ユーザー (資格情報保持者) が、いつ、どのような ID を主張するかを選択できるモデルに移行しつつあります。 どのような信頼当事者/検証者、そしてどのような種類の情報を開示するのか。 後者のタイプのユーザー中心のアイデンティティ エコシステムは、「自己主権アイデンティティ」、「検証可能な認証情報」、「ウォレットベースの認証情報」などとしてさまざまに知られています。
    研究と教育のアイデンティティとアクセス管理エコシステムが成長し、この新しい環境と一連の期待に適応する必要があるかどうか、なぜ、どのように成長する必要があるかを理解するには、これらのテクノロジーの導入のユースケースと推進要因を理解する必要があります。 CACTI メンバーが単独で、より大きなコミュニティの強力な参加なしに、意味のある、または包括的なユースケースを導き出すことは不可能です。 そのために学習者、教師、研究者、管理者、卒業生など、多様なユーザー コミュニティの視点を入れることしました。

    伝統的に大学はSAMLを使ったフェデレーションを構成しているわけですが、Verifiable Credentialをどのように利活用するか?はやはりグローバルでも大きなアジェンダになっている、ということですね。
    ワーキンググループの成果についてこう続きます。

    ワーキング グループは、比較的短い期間で「次世代認証情報」の意味を独自に定義し、InCommon および REFEDS コミュニティからユース ケースを収集するための呼び出しを作成しました。 2023 年 9 月の Internet2 Tech Exchange 会議での発表期限までに、このグループの会議は合計 8 回ありました。最初の会議は用語の定義と理解を構築するために費やされました。 多くの参加者がこのプロセスに意見を提供しました。 ワーキンググループのメンバーは、期限までに 31 のユースケースを収集して文書化し、最初の 8 つのユースケースを詳細に分析しました。 これらのサブセットは、今後の作業への推奨のために選択されましたが、後続の作業グループは、将来の検証に備えたアーキテクチャを定義するためにユースケースを使用する前に、ユースケースをさらに解釈して改良する必要があります (コミュニティの新しい調査からの追加の可能性もあります)。


    Appendixに各ユースケースの説明がありますが、本当に多くのケースが集まりました。このケースから3つのケースに絞り込んで実際の検討を行っていったわけです。

    次回はナラティブあたりを見ていきます。

    CACTIの次世代クレデンシャルに関するレポート(2)

    $
    0
    0

    こんにちは、富士榮です。

    昨日に引き続きCACTIの次世代クレデンシャルに関するレポートを見ていきましょう。

    今回はナラティブのところからです。


    ナラティブとして背景〜ワーキンググループの作業の流れを説明しています。


    電子 ID の状況は、従来のフェデレーション Web シングル サインオン インフラストラクチャで使用されていた強力な集中型モデルから、ユーザーがどのような ID を主張するか、誰とどのような種類の ID を主張するかを選択できるモデルに移行しつつあります。 取引の際に開示する情報。 過去 30 年以上にわたってワールドワイド Web 上のユーザーに影響を与えてきた深刻なプライバシー侵害を制限する取り組みでは、(現在の InCommon および eduGAIN フェデレーション システムと同様に) 依存するリスクがますます高くなる中核的な Web プリミティブからの移行も必要です)。 次世代クレデンシャルワーキング グループは、可能な限り多くの利害関係者の観点から、次世代クレデンシャルの導入に向けた幅広い想定されるユースケースと推進要因を収集し、それらの認証情報との親和性と投資収益率 (ROI) を分析するために設立されました。 目標は、概念実証 (POC) に高い ROI のユースケースを推奨することです。


    目標は先にも書いた通り次世代クレデンシャル(VCを念頭)をどうやって利活用していくか?をユースケース分析を通して明確にしていくことですね。やはりどこの業界でもそうですがユースケースが大事です。一方でチャンピオンユースケースがいまだに見つかっていない、という課題はとても大きく、ブレークスルーが求められます。


    この作業グループはさまざまな機関や組織の 24 人で構成され、2023 年 6 月 15 日から 8 回会合を開きました。このグループは、次世代資格情報の設計と実装に関して競合する理論があるという事実を認識していました。 これらのテクノロジーは、「自己主権アイデンティティ」、「検証可能な資格情報」、「ウォレットベースの資格情報」などの名前で知られています。また、このグループは、この分野で取り組んでいる他の人の成果を再現することも望んでいませんでした。 ワーキンググループは、私たちのコミュニティができることに焦点を当てることにしました。

    適切な使用例を開発するには、次世代の資格情報を構成するものについてグループが共通の理解を得る必要がありました。 このグループは、次世代資格情報の次の実用的な定義を採用しました。 これは、W3C の検証可能な資格情報とほぼ一致しています。

    次世代資格情報は、エンティティ (自然人、システム、組織など) に関する情報を伝達する機械検証可能な方法であり、そのエンティティによって自己主張されるか、発行者から検証者にそのエンティティについて証明されます。 所有者によって管理されるウォレットの意味。 それは、安全でプライバシーを強化し、相互運用可能であり、ユーザーが管理下にある情報の公開について有意義な決定を下せるように通知し、権限を与えるユーザー エクスペリエンスを提供し、取り消し可能である必要があります。

    それほど正式には述べられていませんが、出生証明書、運転免許証、学歴などのサブジェクトに関する属性の束であり、必要に応じて所有者が提示できます。 次世代の認証情報エコシステムにおける決定的な違いは、サービス プロバイダーが認証情報を発行者からではなくユーザーから直接受け取るようになったことです。 採用された実用的な定義は、認証に次世代の資格情報を使用することを妨げるものではありませんが、グループのコンセンサスは、これらのユースケースはグループにとって検討すべき最も興味深いものではなく、適切ではないということでした。


    この辺りはVCの特徴の説明です。まぁ特に目新しいところはありません。

    これらの特徴を踏まえてこのワーキンググループで何をするか?を考えていきます。

     

    このグループは、次世代の資格情報がその可能性を最大限に発揮するには、次世代の資格情報エコシステムの目標、設計、運用が透明でなければならないことを認識しました。

    相互運用性、信頼モデル、取り消し可能性、ユーザー エクスペリエンスの 4 つの主要な特性を考慮します。

    まず、次世代の認証情報は相互運用可能である必要があります。 業界は相互運用不可能なエコシステムを構築する傾向があります。 CACTI は、この分野での標準化を目指す既存の取り組みに参加するとともに、不足している標準化をさらに推進することを検討する必要があります。 OpenID Federation、OpenID4VCI、OpenID4VP などの新しい標準によってサポートされるモデルの展開とテストの分野では、多くの作業が必要です。 InCommon コミュニティは、既存の認証技術の導入の複雑さとコストを考慮して、これらの新しいシステムの価値を実証する価値の高いユースケースを選択し、認証システム、ウォレット、検証者、発行者、および信頼ファブリックのデモンストレーションまたはパイロットを検討する必要があります。 多くのデプロイ担当者にとって。 コミュニティは、強調されているもののまだ満たされていないニーズをサポートする既存のプロトコルの必要な拡張や修正を積極的に追求する準備を整える必要があります。 この作業は、国際的および分野を超えた協力と展開の互換性に重点を置いて進められなければなりません。


    やっぱり多くのIdentity Providerをトラストフレームワークの中で運用してきた経験からもTrust Chainの構築にOpenID Federationを使うことを検討していくことになるんでしょうね。

    相互運用性とエコシステムについても語られています。


    商用製品との相互運用性は最も重要ですが、Google、Apple などの大手企業は、プライバシーを保護したり、容易な移植性や他のエコシステムとの相互運用性を実現したりすることを積極的に阻害しています。 Apple または Google ウォレット (それぞれ Apple Pay、Google ウォレット) の「壁に囲まれた庭園」に閉じ込められたことのある人なら、あるモバイル エコシステムから別のモバイル エコシステムに移行しようとするときに、これがどれほどイライラすることになるかを知っているでしょう。 したがって、InCommon コミュニティは、電子市民権、奨学金、その他の要件に向けた欧州委員会の資金提供による大規模ウォレットのパイロットなど、オープンウォレットの標準化における積極的な世界的な取り組みと協力することが重要です。 この作品の一例は「wwwallet」です。


    なるほど、John Bradleyが入っていた理由の一つが「wwwallet」だったわけですね。

    テクノロジーの相互運用性に加えてトラスト・モデルについても語られます。この辺りは長くトラストフレームワークを運用してきたInCommonならです。さすがです。


    第 2 に、次世代のクレデンシャルでは、新しい信頼モデルの採用が必要になる可能性が高く、確実に新しい信頼インフラストラクチャが必要になります。 現在の信頼モデルでは、エンドユーザーは ID プロバイダーによる機密情報の開示に同意できる場合とできない場合があります。 現在のモデルでは、REFEDS Research and Scholarship (R&S) カテゴリなどの SAML エンティティ カテゴリを使用して、これをある程度安全にしようとしています。 これらのカテゴリはモノリシックで脆弱であり、認証/認可 (ログイン) トランザクションのコンテキストでユーザーに簡単に開示することはできません。 この古典的なモデルでは、ID プロバイダーがデータを管理しているため、機密データを含む証明書利用者に送信される内容を制御できます。 次世代のケースでは、保有者が情報の公開をコントロールします。 エコシステムがプライバシーを要件として構築されている場合、特に低遅延アキュムレータ スキームのようなシステムを介した失効チェックなどのアクションを集約する手段を通じて、発行者はユーザー/所有者による検証者への情報の公開を把握できなくなりますし、検証者による失効チェックについても把握できなくなります。

    大規模な SAML ベースのシングル サインオン フェデレーションの現在の展開モデルは、非常に脆弱でモノリシックです。 XML に基づく脆弱な集計と非機敏な暗号化プロセスは、展開されている既存のエコシステムの長期的な存続可能性を損なう恐れがあります。 次世代モデルは、SAML と OAuth に関する数十年の経験から学んだ教訓に基づいて、標準を介して俊敏性と相互運用性を強化することで、この問題を軽減します。 これまで存在しなかったコンポーネントは、プライバシー、相互運用性 (標準/暗号化プリミティブ)、およびエンドユーザー エクスペリエンスのサポートと強制という点でおそらく最も重要な役割を果たしているため、このコンポーネントであるウォレットがその中核であり、おそらく最も重要な部分となります。 そしてそれはパイロット、標準化、教訓、および以前の作業の改良を通じて行われる作業などを通して実現されます。


    SAMLでは事前のメタデータ交換に基づく(テクニカルな意味での)相互信頼に基づくため、確かにモノリシックであり、大規模環境下で運営するために大きな労力が必要となりますし、どうしてもIdPが強大な力を持つため、利用者による情報コントロールの面で難点があります。ここをウォレットを中心としたモデルで解決することが期待されます。


    第3に、次世代のクレデンシャルは取り消し可能である必要があります。 資格情報には、発行時に有効期間が定義されている場合もあれば、発行者と所有者の両方が合意した将来の条件によって期限切れになる場合もあります。 取り消しは、イベントによって資格情報の再発行が必要になる場合や、個々のデータ要素が無効化され再発行する必要がある場合にも必要です。 クレデンシャル全体またはクレデンシャル内のデータ要素のアクティブでほぼリアルタイムの失効と再発行は、発行者、検証者、そして最も重要なことにウォレットによってサポートされている必要があります。 ユーザーの地理的隔離によるオフラインのウォレットおよび/または検証器の問題 (たとえば、インターネット アクセスが利用できない遠隔地のフィールド ステーションで消耗品を購入するためにウォレット内の資格情報を使用する) は、エッジ ケースであることが証明される可能性があります。 挑戦的。 解決策を追求するためにコミュニティの時間やその他のリソースへの投資を最適化する方法を決定する際には、パレートの法則を考慮する必要があります。

    信頼モデルと資格情報の取り消しの両方に関するグループの議論により、信頼レジストリの必要性が確認されました。 これらのレジストリは、ある意味、InCommon Federation が現在運用している信頼フレームワークに似ていることに注意してください。 この既存の信頼フレームワークは、潜在的な将来の信頼モデルへの入力としてすでに学んだ教訓を活用する機会を提供する可能性があります。 とはいえ、これらのテクノロジーをサポートする新しい信頼レジストリ エコシステムのサポートはグリーンフィールドになる可能性が非常に高いため、慎重に計画して実装する必要があります。 エコシステム実現のこの側面は、真に相互運用可能で安全でユーザーフレンドリーなウォレットの作成と同じくらい困難なものになるでしょう。


    なるほど、やはり既存のトラストフレームワークの考え方を踏襲しつつ、トラストリストや執行リストをレジストリに保管していくことになるわけですね。

    しかし、このモデルは既存のSAMLメタデータをトラストフレームワークで管理していたモデルと何が違うのか?については注意深く見ていく必要があります。SAMLでいいじゃないか?という話になりがちなわけです。その点については後半に述べられているようにオフラインのユースケースを考慮する、というところで違いを出しているわけですね。


    最後に、次世代のクレデンシャルでは、発行者と検証者の両方を検証し信頼する責任がユーザーに課されます。 ユーザーエクスペリエンスは、ユーザーが何を、誰に、どのような目的で、どのような範囲と制約で開示するよう求められているかを簡単に理解し、ユーザーの誠実で情報に基づいた決定に柔軟に対応して、ユーザーの好みや決定に対応できるものでなければなりません。 。 取引を完了するために必要な最小限の開示は、ユーザーに明確に伝えなければなりませんが、ユーザーが選択した場合には追加の属性のリリースも許可する必要があります。 このタイプのユーザー エクスペリエンスのサポートは、エコシステム内のすべての関係者 (発行者、検証者、ウォレット、および信頼レジストリ) に義務付けられていますが、おそらく最も中心に位置し、ウォレット自体内でユーザーに直接表示されます。


    ここも信頼モデルがどう変わるのか、問題です。これまでも本ブログや各所で話をしてきたことですが、ユーザがIssuer/Verifierの正当性を検証しなければならないモデルになってしまうので、どうしても使う人を選んでしまいそうな点は懸念です。


    次回はパイロット、ユースケース選定あたりを見ていきましょう。

    CACTIの次世代クレデンシャルに関するレポート(3)

    $
    0
    0
    こんにちは、富士榮です。

    このレポートを見ていくのも最後です。最後はユースケースの話です。

    パイロットとユースケースについてこのように分類しています。
    広くユースケースの募集をしていました。
    パイロットは、研究および教育部門ではやや独特な問題に焦点を当てる必要があります。学生、教職員、およびスタッフは、多くの場合、機関間および機関内の承認に使用する必要がある非常に多くのグループと役割を担っています。 これらのグループ メンバーシップは、セキュリティ上の理由からリアルタイムの失効に大きく依存しており、グループの数が膨大であるため、大規模な承認に対して課題、別名「Kerberos PAC フィールド問題」が発生することがよくあります。 この分野におけるもう 1 つの特有のニーズは、eduperson、voperson、SCHAC などのカスタマイズされたスキーマのサポートです。 コミュニティは、検証可能な資格情報スペースの既存のオープンスタンダード内でこれらのスキーマをどのように適応させて使用できるかを調査する必要があります。
    ワーキンググループは 31 のユースケースを収集しました。 ユースケースの違いを示す最も顕著な側面の 1 つは、各ケースで R&E 機関が果たす役割です。 多くの場合、教育機関は卒業証書や学生証などの資格情報の発行者です。 他の場合には、その機関が、おそらく別の学術機関からの資格の検証者です。 また、場合によっては、機関自体が資格情報を保持していることもあります。 これらのカテゴリのうち最初の 2 つ、つまり発行者および検証者としての機関が、最もすぐに対応できると思われます。 そこで、グループは、これらのカテゴリを最もよく表すユースケースを選択しようとしました。
    31!結構な数です。あまり私たちはコントリビュートできませんでしたが、いろいろなケースが存在します。

    作業グループは、次の 3 つの使用例を検討することに同意しました。
    学生は、現在の学業状況以外のことを明らかにすることなく、在学生にのみ提供されるサービス割引を受けるために、サービスプロバイダーに検証可能な資格情報を提示します。
    大学は入学希望者の高校卒業資格および/または成績証明書を確認する必要があります。
    雇用主は、将来の従業員の大学の卒業証書および/または成績証明書を確認する必要があります。
     
    やはりアカデミックと言うことでアクターとして学生と雇用を考えるわけです。
    ユースケース 1 は、次世代認証情報の魅力的なユースケースと考えられていました。 これは理解しやすく、次世代認証情報のプライバシー強化の可能性を明確に示しています。 まず、ユーザーは現在の学歴をプロバイダーに提示するだけでよく、他の情報はすべて隠します。 第 2 に、資格情報の発行者 (おそらく教育機関) は、ユーザーがサービス割引を有効にしたことに気づいていません。
    ユースケース 2 と 3 は似ていますが、各ケースで機関はエコシステム内で異なる役割を引き受けます。 ケース 2 では、教育機関が検証者として機能し、ケース 3 では、教育機関が学歴証明書の発行者として機能します。 どちらの場合も、従来の境界を超えた相互運用性と信頼が基本的な要件です。
    ユースケース 3 では、次世代認証情報の性質から得られるセキュリティ上の利点も強調しています。 教育機関が資格情報を発行すると、所有者はその資格情報を直接提示できます。 卒業証書や成績証明書を保持する仲介者がいないため、侵害の可能性がさらに高まります。 組織にとって、攻撃対象領域が小さくなり、侵害範囲がより限定されることによるリスクの潜在的な削減は、説得力のあるものとなるはずです。

    WGでは1つ目のユースケースにフォーカスを置いて議論を進めています。
    ワーキンググループは、ユースケース 1 が次世代の認証情報エコシステムの期待と利点を最もよく表しており、かつ理解しやすいものであることに同意しました。 個人の学業上の地位を主張することは、学術機関が実行する基本的な機能であり、割引の引き換えだけに限定されるものではありません。 ほとんどのユーザーは、学歴を証明するために既存の資格認証テクノロジーを使用することに慣れています。 機関とユーザーの両方が慣れ親しんだ既存のプロセスとして、次世代認証情報のプライバシー強化機能を強調しながら、テクノロジーを直接比較する機会を提供します。
    これらの最初の非常に単純な使用例をサポートできるパイロット アーキテクチャを構築するには、多くの領域でさらなる作業が明らかに必要です。 ワーキング グループは、InCommon のコミュニティ ガバナンス領域の全領域に及ぶ可能性のある後続の活動を推奨しており、大規模なアーキテクチャ、信頼モデル、標準、運用要件と展開要件、グローバルな相互運用性、内部での反復実装を調査するために必然的に新しいワーキング グループを作成します。

    なかなか難しい問題ですが、結局のところ、トラストフレームワークの中で管理されている学生とその外にある人たちをどうやってコラボレーションさせるか、というなところがやはり次世代のクレデンシャルで解決すべき問題になるんじゃないかな、と思ったりもしました。
    これをコミュニティとガバナンスの問題に閉じこめたらダメなんじゃないかと思いました。

    ということでこのレポートは以下の結論で締めくくっていますす。
    CACTI と InCommon Technical Advisory Committee (TAC) は、2024 年の第 1 四半期に開始し、2024 年 9 月末の終了日を目標として、共同作業グループの取り組みを開始し、実証のためのユースケースをさらに絞り込む必要があります。 これらのユース ケースを使用して、InCommon 信頼環境内で検証可能な資格情報テクノロジを使用する概念実証の展開のための高レベルのアーキテクチャと技術要件を定義します。 可能であれば、コミュニティのニーズとその要件に合わせて、既存の機能、機能、およびビジネス プロセスの使用を検討する必要があります。 この作業グループは、概念実証のためのソフトウェアおよびシステム要件に関する規範文書だけでなく、高レベルのアーキテクチャを説明する規範文書を作成する任務を負う必要があります。
    まぁ、結論というかなんと言うかの締めくくりですが、今後も検討をしていかないといけないテーマなんだと思います。
    Viewing all 769 articles
    Browse latest View live