こんにちは、富士榮です。
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月末時点）
こんにちは、富士榮です。
これまでも何度か本ブログで取り上げてきた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.
このうち、２番目のチャンピオンユースケースの実現に向けたデジタルIDに関する最低限の相互運用性要件の定義、３番目のトラストフレームワークのマッピングに関する定例会議が始まりました。
それぞれ、以下の曜日・時間帯でスタートします。
※時差計算は苦手なので間違っていたらすみません。
こちらのページで興味のあるワークストリームに登録をすると案内メールが流れてくるので、その中に参加用のTeams会議のリンクがあります。ぜひ参加しましょう。
パイロットは、研究および教育部門ではやや独特な問題に焦点を当てる必要があります。学生、教職員、およびスタッフは、多くの場合、機関間および機関内の承認に使用する必要がある非常に多くのグループと役割を担っています。 これらのグループ メンバーシップは、セキュリティ上の理由からリアルタイムの失効に大きく依存しており、グループの数が膨大であるため、大規模な承認に対して課題、別名「Kerberos PAC フィールド問題」が発生することがよくあります。 この分野におけるもう 1 つの特有のニーズは、eduperson、voperson、SCHAC などのカスタマイズされたスキーマのサポートです。 コミュニティは、検証可能な資格情報スペースの既存のオープンスタンダード内でこれらのスキーマをどのように適応させて使用できるかを調査する必要があります。
ワーキンググループは 31 のユースケースを収集しました。 ユースケースの違いを示す最も顕著な側面の 1 つは、各ケースで R&E 機関が果たす役割です。 多くの場合、教育機関は卒業証書や学生証などの資格情報の発行者です。 他の場合には、その機関が、おそらく別の学術機関からの資格の検証者です。 また、場合によっては、機関自体が資格情報を保持していることもあります。 これらのカテゴリのうち最初の 2 つ、つまり発行者および検証者としての機関が、最もすぐに対応できると思われます。 そこで、グループは、これらのカテゴリを最もよく表すユースケースを選択しようとしました。
作業グループは、次の 3 つの使用例を検討することに同意しました。
学生は、現在の学業状況以外のことを明らかにすることなく、在学生にのみ提供されるサービス割引を受けるために、サービスプロバイダーに検証可能な資格情報を提示します。
大学は入学希望者の高校卒業資格および/または成績証明書を確認する必要があります。
雇用主は、将来の従業員の大学の卒業証書および/または成績証明書を確認する必要があります。
ユースケース 1 は、次世代認証情報の魅力的なユースケースと考えられていました。 これは理解しやすく、次世代認証情報のプライバシー強化の可能性を明確に示しています。 まず、ユーザーは現在の学歴をプロバイダーに提示するだけでよく、他の情報はすべて隠します。 第 2 に、資格情報の発行者 (おそらく教育機関) は、ユーザーがサービス割引を有効にしたことに気づいていません。
ユースケース 2 と 3 は似ていますが、各ケースで機関はエコシステム内で異なる役割を引き受けます。 ケース 2 では、教育機関が検証者として機能し、ケース 3 では、教育機関が学歴証明書の発行者として機能します。 どちらの場合も、従来の境界を超えた相互運用性と信頼が基本的な要件です。
ユースケース 3 では、次世代認証情報の性質から得られるセキュリティ上の利点も強調しています。 教育機関が資格情報を発行すると、所有者はその資格情報を直接提示できます。 卒業証書や成績証明書を保持する仲介者がいないため、侵害の可能性がさらに高まります。 組織にとって、攻撃対象領域が小さくなり、侵害範囲がより限定されることによるリスクの潜在的な削減は、説得力のあるものとなるはずです。
ワーキンググループは、ユースケース 1 が次世代の認証情報エコシステムの期待と利点を最もよく表しており、かつ理解しやすいものであることに同意しました。 個人の学業上の地位を主張することは、学術機関が実行する基本的な機能であり、割引の引き換えだけに限定されるものではありません。 ほとんどのユーザーは、学歴を証明するために既存の資格認証テクノロジーを使用することに慣れています。 機関とユーザーの両方が慣れ親しんだ既存のプロセスとして、次世代認証情報のプライバシー強化機能を強調しながら、テクノロジーを直接比較する機会を提供します。
これらの最初の非常に単純な使用例をサポートできるパイロット アーキテクチャを構築するには、多くの領域でさらなる作業が明らかに必要です。 ワーキング グループは、InCommon のコミュニティ ガバナンス領域の全領域に及ぶ可能性のある後続の活動を推奨しており、大規模なアーキテクチャ、信頼モデル、標準、運用要件と展開要件、グローバルな相互運用性、内部での反復実装を調査するために必然的に新しいワーキング グループを作成します。
CACTI と InCommon Technical Advisory Committee (TAC) は、2024 年の第 1 四半期に開始し、2024 年 9 月末の終了日を目標として、共同作業グループの取り組みを開始し、実証のためのユースケースをさらに絞り込む必要があります。 これらのユース ケースを使用して、InCommon 信頼環境内で検証可能な資格情報テクノロジを使用する概念実証の展開のための高レベルのアーキテクチャと技術要件を定義します。 可能であれば、コミュニティのニーズとその要件に合わせて、既存の機能、機能、およびビジネス プロセスの使用を検討する必要があります。 この作業グループは、概念実証のためのソフトウェアおよびシステム要件に関する規範文書だけでなく、高レベルのアーキテクチャを説明する規範文書を作成する任務を負う必要があります。
こんにちは、富士榮です。
昨日に引き続き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が強大な力を持つため、利用者による情報コントロールの面で難点があります。ここをウォレットを中心としたモデルで解決することが期待されます。
第３に、次世代のクレデンシャルは取り消し可能である必要があります。 資格情報には、発行時に有効期間が定義されている場合もあれば、発行者と所有者の両方が合意した将来の条件によって期限切れになる場合もあります。 取り消しは、イベントによって資格情報の再発行が必要になる場合や、個々のデータ要素が無効化され再発行する必要がある場合にも必要です。 クレデンシャル全体またはクレデンシャル内のデータ要素のアクティブでほぼリアルタイムの失効と再発行は、発行者、検証者、そして最も重要なことにウォレットによってサポートされている必要があります。 ユーザーの地理的隔離によるオフラインのウォレットおよび/または検証器の問題 (たとえば、インターネット アクセスが利用できない遠隔地のフィールド ステーションで消耗品を購入するためにウォレット内の資格情報を使用する) は、エッジ ケースであることが証明される可能性があります。 挑戦的。 解決策を追求するためにコミュニティの時間やその他のリソースへの投資を最適化する方法を決定する際には、パレートの法則を考慮する必要があります。
信頼モデルと資格情報の取り消しの両方に関するグループの議論により、信頼レジストリの必要性が確認されました。 これらのレジストリは、ある意味、InCommon Federation が現在運用している信頼フレームワークに似ていることに注意してください。 この既存の信頼フレームワークは、潜在的な将来の信頼モデルへの入力としてすでに学んだ教訓を活用する機会を提供する可能性があります。 とはいえ、これらのテクノロジーをサポートする新しい信頼レジストリ エコシステムのサポートはグリーンフィールドになる可能性が非常に高いため、慎重に計画して実装する必要があります。 エコシステム実現のこの側面は、真に相互運用可能で安全でユーザーフレンドリーなウォレットの作成と同じくらい困難なものになるでしょう。
なるほど、やはり既存のトラストフレームワークの考え方を踏襲しつつ、トラストリストや執行リストをレジストリに保管していくことになるわけですね。
しかし、このモデルは既存のSAMLメタデータをトラストフレームワークで管理していたモデルと何が違うのか？については注意深く見ていく必要があります。SAMLでいいじゃないか？という話になりがちなわけです。その点については後半に述べられているようにオフラインのユースケースを考慮する、というところで違いを出しているわけですね。
最後に、次世代のクレデンシャルでは、発行者と検証者の両方を検証し信頼する責任がユーザーに課されます。 ユーザーエクスペリエンスは、ユーザーが何を、誰に、どのような目的で、どのような範囲と制約で開示するよう求められているかを簡単に理解し、ユーザーの誠実で情報に基づいた決定に柔軟に対応して、ユーザーの好みや決定に対応できるものでなければなりません。 。 取引を完了するために必要な最小限の開示は、ユーザーに明確に伝えなければなりませんが、ユーザーが選択した場合には追加の属性のリリースも許可する必要があります。 このタイプのユーザー エクスペリエンスのサポートは、エコシステム内のすべての関係者 (発行者、検証者、ウォレット、および信頼レジストリ) に義務付けられていますが、おそらく最も中心に位置し、ウォレット自体内でユーザーに直接表示されます。
ここも信頼モデルがどう変わるのか、問題です。これまでも本ブログや各所で話をしてきたことですが、ユーザがIssuer/Verifierの正当性を検証しなければならないモデルになってしまうので、どうしても使う人を選んでしまいそうな点は懸念です。
2023 年 4 月、Internet2 の Trust and Identity Services 部門のアーキテクチャ ガバナンス グループである Internet2 Community Architecture for Trust and Identity (CACTI) は、研究と教育 (R&E) のアイデンティティとアクセスに関する世界的な参加を求めるオープンなワーキング グループを設立しました。 管理 (IAM) コミュニティ。R&E ミッションをサポートする新しいテクノロジーの採用の可能性を探ります。
電子 ID の状況は、従来のフェデレーテッド Web シングル サインオン インフラストラクチャで使用されていた強力に集中化されたモデルから、ユーザー (資格情報保持者) が、いつ、どのような ID を主張するかを選択できるモデルに移行しつつあります。 どのような信頼当事者/検証者、そしてどのような種類の情報を開示するのか。 後者のタイプのユーザー中心のアイデンティティ エコシステムは、「自己主権アイデンティティ」、「検証可能な認証情報」、「ウォレットベースの認証情報」などとしてさまざまに知られています。
研究と教育のアイデンティティとアクセス管理エコシステムが成長し、この新しい環境と一連の期待に適応する必要があるかどうか、なぜ、どのように成長する必要があるかを理解するには、これらのテクノロジーの導入のユースケースと推進要因を理解する必要があります。 CACTI メンバーが単独で、より大きなコミュニティの強力な参加なしに、意味のある、または包括的なユースケースを導き出すことは不可能です。 そのために学習者、教師、研究者、管理者、卒業生など、多様なユーザー コミュニティの視点を入れることしました。
ワーキング グループは、比較的短い期間で「次世代認証情報」の意味を独自に定義し、InCommon および REFEDS コミュニティからユース ケースを収集するための呼び出しを作成しました。 2023 年 9 月の Internet2 Tech Exchange 会議での発表期限までに、このグループの会議は合計 8 回ありました。最初の会議は用語の定義と理解を構築するために費やされました。 多くの参加者がこのプロセスに意見を提供しました。 ワーキンググループのメンバーは、期限までに 31 のユースケースを収集して文書化し、最初の 8 つのユースケースを詳細に分析しました。 これらのサブセットは、今後の作業への推奨のために選択されましたが、後続の作業グループは、将来の検証に備えたアーキテクチャを定義するためにユースケースを使用する前に、ユースケースをさらに解釈して改良する必要があります (コミュニティの新しい調査からの追加の可能性もあります)。
こんにちは、富士榮です。
ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。（実装ミスは問題外として）
他にもあればぜひご意見ください。
こんにちは、富士榮です。
パスキーを使う際に、AppleやGoogle、Microsoftなどのクラウドプラットフォームを通じたデバイス間で鍵の同期を行うSyned Passkeysをどう扱うか？、つまりそもそもFIDO認証の良いところはデバイスとの紐付けが強固であることだったはず、一方で鍵のリカバリが認証強度の弱点となりクレデンシャルの盗難や不正利用のきっかけになってしまう、その意味で鍵の同期は必要なのである、といった論争もひと段落してきたわけですが、その意味でパスキーを念頭においた各種ガイドラインについても更新される時期が来ているのかもしれません。
今回、NISTからSP800-63Bに関する同期可能な認証器に関する補足文書が公開されています。
アナウンス原文はこちら）
公開された文書はこちら）
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) での使用を許可するための追加の要件と考慮事項が規定されています。
多くのことが変わりました。ガイドラインが最初に開発および発行された時点では、同期可能な認証システムをサポートするための標準と仕様は開発されていませんでした。それ以来、標準は成熟し、ほとんどの主要な消費者プラットフォームが同期可能な認証システムのサポートを導入しました。 FIDO Alliance はこれまでのところ、80 億を超えるユーザー アカウントが認証にパスキーを使用するオプションを備えていると推定しています。まだどこにでも普及しているわけではありませんが、日に日に一般的になってきています。
そう、リスクは常に存在するのです。補足の要件は、キーの保存、送信、保護の方法を含め、これらの要件にできるだけ多く対処することを目的としています。同期可能なオーセンティケーターには特有のリスクが伴います。特に、一部の技術実装におけるユーザーが自分の認証キーを他の個人と共有する機能です。認証子を共有する機能は同期可能なキーに固有のものではなく、ほぼすべての AAL2 認証子を共有できます。しかし、長年のセキュリティ ポリシーに反して、一部の実装では、多くの消費者シナリオでパスワード共有の安全な代替手段として同期可能な認証子の共有を推進しています。
すべてのインスタンスと同様に、組織は、提供するあらゆるタイプの認証システムを評価し、実装する前にそれに伴うメリットとリスクを比較検討する必要があります。同期可能なオーセンティケータは、すべてのアプリケーションやサービスに適しているわけではありませんが、エンドユーザーと信頼当事者の両方に多くのメリットをもたらす、新たな AAL2認証器オプションとなります。
この更新文書には適していません 。 SP 800-63-4 に関する最初のパブリック コメント期間からのフィードバックがこの補足資料に組み込まれました。同期可能な認証システムと補足の全体的な内容に関する追加のコメントは、リビジョン 4 の今後の第 2 回パブリック コメント期間を通じて提出できます。これは今年後半に行われる予定です。
上で述べたように、デジタル ID ガイドラインの規範文に厳密に従っている政府機関は、同期可能な認証システムを使用することを許可されません。この補足では、連邦ゼロトラスト戦略をサポートする強力で使いやすく、フィッシング耐性のある認証を提供する新しいセキュリティ技術の使用方法についての指示を提供することで、多くの政府機関の当面のニーズに対応しています。リビジョン 4 が完成すると、この補足は廃止されます。
技術や状況は日々変わってきているので柔軟にガイドラインも対応していく必要がありますね。
Adminダッシュボード
Learner Wallet
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
の３行です。私はテスト用にmailtrapを使ったので必要なSMTPホストやユーザID、パスワードはmailtrapのサンドボックスの値を使いました。
こんにちは、富士榮です。
先日リリースされた自民党の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
こんにちは、富士榮です。
いよいよ最終日でした。
一昨日、昨日に引き続きIIW（Internet Identity Workshop）のクイックレビューです。
あたりを記録しておきたいと思います。
投稿
すべてのコメント
