2024年4月30日火曜日

VC-JOSE-COSEがCRに

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

VC-JOSE-COSEがW3CのCR(勧告候補)になっていますね。

https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/



Mike Jonesも書いているように先日同じく勧告候補になったVCDM(Verifiable Credentials Data Model)v2.0では前のバージョンと異なりクレデンシャルフォーマットにJSON-LDだけをサポートするようになっています。

一方でこのVC-JOSE-COSEはJOSE、SD-JWT、COSEをスコープとしているのでなんだかチグハグな感じになりつつあります。

まぁ、そもそもクレデンシャルフォーマットがISOのmDoc、IETFのSD-JWTやJWP、W3CのVCDMと割れてしまっているが今後どうなっていくんだろうか・・・という話ではあるんですが。

追記)崎村さんからOpen Wallet Foundationが見ているクレデンシャルフォーマットの一覧を頂いたので貼っておきます。16種類もある・・・(2024年4月末時点)

https://github.com/openwallet-foundation/credential-format-comparison-sig/tree/main/data/Credential-Format






2024年4月29日月曜日

SIDI Hubの活動が本格的に開始されています

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

これまでも何度か本ブログで取り上げてきたSIDI Hubですが、いよいよ活動が本格的に開始されています。


おさらいですが、現在、SIDI Hubのワークストリームは以下の通り定義されています。

1. Champion Use Cases for cross-border interoperability, develop a process for selecting and fleshing out 1-3 cross-border use cases.

2. Minimum Requirements for Digital Identity Interoperability for Champion Use Cases.

3. Trust Framework Mapping for Champion Use Cases, by analysing and amplifying existing trust mapping efforts, identifying gaps (including duplication), and aligning on mitigation tactics.

4. Metrics of success Define what SIDI Hub metrics of success are, and monitoring delivery.

5. SIDI Hub Governance, such as SIDI Hub internal processes & grant management, SIDI decision tracking, SIDI partner issue resolution monitoring, SIDI roadmap alignment, global ecosystem governance gap analysis & options to remediate.

このうち、2番目のチャンピオンユースケースの実現に向けたデジタルIDに関する最低限の相互運用性要件の定義、3番目のトラストフレームワークのマッピングに関する定例会議が始まりました。

それぞれ、以下の曜日・時間帯でスタートします。

  • 最低限の相互運用性要件の定義
    • 毎週月曜日の16:00-17:00(CET)
    • 4/29(UTC)から開始
    • 日本時間で言うと4/29(月)23:00-24:00(つまり今晩)※現在CESTだったので修正
  • トラストフレームワークのマッピング
    • 毎週木曜日の14:30〜15:30(UTC)
    • 5/2(UTC)から開始
    • 日本時間で言うと5/2(木)22:30-23:30※同じく現在CESTだったので修正

※時差計算は苦手なので間違っていたらすみません。


こちらのページで興味のあるワークストリームに登録をすると案内メールが流れてくるので、その中に参加用のTeams会議のリンクがあります。ぜひ参加しましょう。


2024年4月28日日曜日

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

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

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

パイロットとユースケースについてこのように分類しています。
広くユースケースの募集をしていました。
パイロットは、研究および教育部門ではやや独特な問題に焦点を当てる必要があります。学生、教職員、およびスタッフは、多くの場合、機関間および機関内の承認に使用する必要がある非常に多くのグループと役割を担っています。 これらのグループ メンバーシップは、セキュリティ上の理由からリアルタイムの失効に大きく依存しており、グループの数が膨大であるため、大規模な承認に対して課題、別名「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 信頼環境内で検証可能な資格情報テクノロジを使用する概念実証の展開のための高レベルのアーキテクチャと技術要件を定義します。 可能であれば、コミュニティのニーズとその要件に合わせて、既存の機能、機能、およびビジネス プロセスの使用を検討する必要があります。 この作業グループは、概念実証のためのソフトウェアおよびシステム要件に関する規範文書だけでなく、高レベルのアーキテクチャを説明する規範文書を作成する任務を負う必要があります。
まぁ、結論というかなんと言うかの締めくくりですが、今後も検討をしていかないといけないテーマなんだと思います。

2024年4月27日土曜日

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

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

昨日に引き続き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の正当性を検証しなければならないモデルになってしまうので、どうしても使う人を選んでしまいそうな点は懸念です。


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

2024年4月26日金曜日

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

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

先日書いた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つのケースに絞り込んで実際の検討を行っていったわけです。

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

2024年4月25日木曜日

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

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

ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことを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セキュアなどに任せてしまう


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



2024年4月24日水曜日

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

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

パスキーを使う際に、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 が完成すると、この補足は廃止されます。


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

2024年4月23日火曜日

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

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

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で出てくるのは非常にいいですね。うまくコントリビューションしていければと思います。




2024年4月22日月曜日

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

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

先日リリースされた自民党の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


2024年4月21日日曜日

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

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

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


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

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



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

2024年4月20日土曜日

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

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

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

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

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

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

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

2024年4月19日金曜日

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

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

いよいよ最終日でした。

一昨日昨日に引き続き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年後に参加して進捗を見ていきたいと思います。

2024年4月18日木曜日

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

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

昨日に引き続き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との連携している

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