このブログはこちらの英語ブログの機械翻訳です。
検証可能なデジタル認証情報（VDC）に関するブログシリーズのパート4へようこそ！これまでのブログ記事では、VDCが重要な理由、VDCとは何か、そしてVDCが価値を付加する実際のユースケースについてご紹介しました。
この投稿では、VDCエコシステムについてより深く掘り下げ、以下について説明します。
- 主要な用語
- VDCとフェデレーションおよびパスキーの比較
- 標準とプロトコル
- 認証情報の発行と信頼の方法
- OktaとAuth0の適合性
それでは、詳しく見ていきましょう！
用語集
技術的な詳細を理解しやすくするために、以前のブログの花火店のシナリオを再検討してみましょう。オンラインで線香花火や回転花火を購入しようとしていて、ストアがあなたが18歳以上であることを確認する必要があると想像してください。検証可能なデジタル認証情報（VDC）の世界の主要なプレーヤーと概念が、そのエクスペリエンスにどのように対応するかを以下に示します。
関係者
あなたはホルダーです: あなたはクレデンシャルを所持している人です。（場合によっては、親が子供のクレデンシャルを代理で保持することがあります。
花火店は検証者です：年齢を確認するためにクレデンシャルを要求し、検証します。
あなたの州のDMVが発行者です: モバイル運転免許証 (mDL) を発行することで、あなたについて (この場合は、あなたが18歳以上であること) を主張します。
ツール
ウォレットは、資格情報を保存および提示するスマートフォン上のアプリです（資格情報マネージャーの一種であり、より広義にはパスワード、パスキー、およびデジタルIDを管理するためのソフトウェアが含まれます）。
mDL自体が検証可能なデジタル資格情報（VDC）です。これは、暗号的に検証可能なデジタル資格情報です。
信頼とコントロール
チェックアウトするときは、選択的な開示を使用して、完全な生年月日や自宅住所を明かさずに、18歳であるという事実のみを共有できます。
花火店は、DMVが信頼リスト (信頼できる発行者とその暗号化アンカーのレジストリ) の一部であるため、DMVを信頼できると認識しています。
その信頼リストの背景には、発行者がリストに掲載される方法と、従うべき基準を決定する信頼フレームワーク（ビジネスおよびポリシー規則）があります。
VDCは、フェデレーションやパスキーとどのように異なりますか？
VDC はフェデレーションやパスキーに代わるものではありません。それらを補完的なツールと考えてください。フェデレーションはシステム間でアイデンティティを接続し、パスキーは認証を保護し、VDC はポータブルで検証可能な情報をミックスにもたらします。これらを組み合わせることで、より強力でユーザーフレンドリーなアイデンティティ エコシステムが生まれます。
フェデレーション
フェデレーションサインイン（別名ソーシャルサインイン）は、長年にわたり消費者および企業の認証の定番となっています。仕組みは次のとおりです。
- ユーザーは、Google などの Identity Provider (IdP) 経由でサインインします。
- IdPはユーザーを認証し、（名前、メール、電話などのクレームを含む）トークンを発行します。
- トークンはサービスに返送され、ユーザーのアカウントが設定されます。
メリット: ユーザーは別のパスワードを覚える必要がありません。
デメリット: フェデレーションIdPを使用するたびに、アクセスしようとしているサービスと、おおよその場所などのメタデータが通知されます。フェデレーションIdPはワークフォースのコンテキストでは役立ちますが、消費者にとっては重大なプライバシーリスクが生じます。
VDC
- VDC は、進化した形のフェデレーションと考えることができます。
- 発行者（フェデレーションにおけるIdPと同様）は、あなたに関するクレームを主張します。
- あなた（保持者）は、それらのクレームを検証者（フェデレーションのサービスプロバイダーと同様）に提示します。
- 検証者は、1 つまたは複数のトラストリストを使用して有効性を確認します。
重要な違い：VDCで共有されるものを保持し、制御できます。フェデレーション（またはソーシャルログイン）アカウントに個人データを保存する必要はありません。また、フェデレーションアカウントを所有する企業は、あなたの個人情報を保持する必要はなく、あなたがいつ、どのようにそれを使用しているかを知る必要もありません。このように、VDCはあなたのアイデンティティデータに対するより多くの制御を与えることでプライバシーを高めます。
パスキー
パスキーは、パスワード、OTP、およびマジック リンクに代わる、フィッシングに強い代替手段として登場しました。一見すると、それらは VDC と似ているかもしれませんが（どちらも暗号化を含み、ウォレットまたは資格情報マネージャー内に存在する可能性があります）、異なる問題を解決します。
パスキー = 認証用（サービスに対して「自分が本人である」ことを証明する）。
VDCs = クレームを提示するため（あなた自身について何かを証明するため）。
パスキーは、すべてのロックに異なるキーがあるように、各ウェブサイトまたはアプリに固有のものであるため、デフォルトでプライバシーが保護されることに注意することが重要です。サービスが異なるサイト間でパスキーの使用状況をリンクさせることはできません。対照的に、VDC は、オンラインで提示されたときに追跡ベクターにならないようにするために、追加の保護手段（高度な暗号化や一括発行など）を必要とします。
連携の仕組み
パスキー、フェデレーション、VDCは、Identityスタックの異なるレイヤーに対応しており、競合するのではなく、相互に補完的です。実際には、これらは連携して動作することがよくあります。
住宅ローンの申請は、身元を証明するために政府発行のVDCから始まる場合があります。身元が確認され、アカウントが作成されると、将来のログインのためにユーザーにパスキーが作成されます。
アルコール配達サービスは、フェデレーションIdP（例：Googleでサインイン）を介したサインアップを許可し、そのIdPでパスキーを使用して認証し（パスワードに依存しない）、チェックアウト時に政府発行のVDCを要求して年齢を確認する場合があります。
さらに詳しく知りたい場合は、Identiverse 2025の私のセッションをご覧ください：パスキーと検証可能なデジタル資格情報：友人か敵か？
SD-JWT VC、デジタル認証情報 API、Verifiable Presentations 用 OpenID、Oh My
検証可能なデジタル認証情報のエコシステムは非常に広範で、多くの標準開発組織で開発された多くの異なる技術標準が関与しています。標準は、相互運用性をサポートするために、エコシステムのすべての側面をカバーしています：識別子、キー管理、スキーマ、資格情報の形式、プレゼンテーションプロトコル、発行プロトコル、Web APIなど。ここにいくつかのコア標準があります。
クレデンシャルの形式
SD-JWT VCは、選択的開示をサポートするVDCクレデンシャル形式であり、使い慣れた開発者向けのJSON Web Tokenに基づいています。SD-JWT VCは、IETFで開発されています。
ISO 18013-5仕様で定義されているmdoc形式は、主にmDLやその他の政府発行のIDドキュメントに使用されます。mdocはクレデンシャルの構造を定義していますが、ISO 18013-5は発行および物理的な対面使用のルールも指定しています。ISO 18013-7はこれをリモート（オンライン）プレゼンテーションシナリオに拡張し、OpenID4VPやDigital Credentials APIなどの既存の仕様をプロファイルして、Web経由での安全な検証をサポートします。
*注：ISO仕様は無料では入手できず、すべての読者が購入する必要があります。
プロトコル
Verifiable Credential Issuance (OpenID4VCI) 向けの OpenID は、発行者とクレデンシャルマネージャー (ウォレット) が VDC を発行するために情報を交換する方法を定義します。複数のクレデンシャル形式をサポートし、単独で、または Digital Credentials API 経由で使用できます。
OpenID for Verifiable Presentations (OpenID4VP)は、クレデンシャルマネージャー（ウォレット）がVDCを検証者に提示する方法を定義します。このプロトコルはクレデンシャル形式に依存せず、どのウォレットでもサポートできます。OpenID4VPは、従来のリダイレクトベースのフローまたはDigital Credentials APIを介して使用できます。
OpenID4VCI と OpenID4VP は合わせて、OpenID Foundation で開発された、Verifiable Credentials 向けの OpenID ファミリーを形成します。
API
Oktaが一部の業界パートナーと協力して推進している取り組みであるW3C Digital Credentials APIは、VDCエコシステムの重要な要素です。これにより、ウェブやアプリでのVDCの安全でユーザーフレンドリーな発行と提示が可能になります。パスキーのWebAuthn APIに精通している場合、Digital Credentials APIはVDCと同様の役割を果たします。
それが重要な理由：
左側のビジュアル：「カスタムスキーム」を使用したVDCプレゼンテーションフロー—ユーザーにはウォレットを選択するように指示する曖昧なプロンプトが表示され、リクエストに関するコンテキストがありません。
- 適切なビジュアル： Digital Credentials APIを使用したVDCプレゼンテーションフロー—ユーザーは、誰が認証情報を要求しているか、およびそれを実行するための明確なオプションのカルーセルを確認できます。ユーザーは、各認証情報をどこに保存したかを覚えておく必要はありません。
（頭字語など）いくつかの要素をまとめるために、Digital Credentials APIを介してOID4VCIを使用してSD-JWT VCを発行し、Digital Credentials APIを介してOID4VPを使用してSD-JWT VCのプレゼンテーションをリクエストできます！
検証可能なデジタル認証情報はどのようにして入手できますか？
VDCを提示するには、まずVDCが発行される必要があります。これが発生する一般的な方法は2つあります。
1. ウェブサイトまたはアプリから開始される発行
搭乗券やコンサートのチケットを携帯電話に保存するようなものだと考えてください。ウェブサイトまたはアプリで、「ウォレットに追加」を促すボタンが表示されます。VDCの場合、これをクリックするとDigital Credentials APIが起動し、どの資格情報マネージャー（ウォレット）に資格情報を保存するかを尋ねられます。ウォレットは、プロセスを完了するために追加のUIを表示する場合があります。
2. 認証情報マネージャーまたはウォレットが開始した発行
プロセスが資格情報マネージャーまたはウォレットで直接開始される場合があります。これは、米国のmDLや、Google ID Passのような派生資格情報に典型的です。ウォレットは、個別のWebサイトやアプリを必要とせずに、資格情報の要求と保存をガイドします。以下は、Apple Wallet、Google Wallet、Samsung Walletの「ウォレットに追加」画面の例です。
どちらのフローも、シンプル、安全、そして使い慣れたものになるように設計されています。ユーザーがデジタルチケット、ポイントカード、搭乗券などからすでに知っているのと同じパターンを活用しています。
VDCをどのように信頼できますか？
VDCへの信頼は暗号から始まります。検証者は資格情報を受信すると、最初にデジタル署名を確認します。これにより、信頼できる機関によって発行されたことが確認されます。
それを可能にするために、エコシステムは信頼リストと信頼フレームワークに依存しています。信頼リストは、基本的に、信頼できるエンティティとその署名キーの厳選されたセットです。ブラウザのトラストストア内のルート CA (認証局) のようなものと考えてください。信頼フレームワークは、発行者がリストに載る方法に関するルールとポリシーを定義し、ビジネス要件と技術要件の両方を組み合わせます。
mDLを例にとると、米国とカナダでは、州および地方のDMVが、American Association of Motor Vehicle Administrators（AAMVA）Digital Trust Serviceを通じて署名キーを公開しています。これらのキー（Issuing Authority Certification Authorities（IACA）と呼ばれます）は、信頼のアンカーとして機能します。OktaやAuth0のようなプラットフォームは、AAMVAと定期的に同期して、新しい発行者が自動的に認識されるようにすることができます。
このモデルは政府の ID に限定されません。教育では、連邦はすでに大学や国全体で信頼を仲介しています。ヘルスケア、金融、その他のセクターでは、業界団体が同様の役割を果たしています。これらのトラストリストとフレームワークは、VDC のドメインおよび国境を越えた相互運用性と信頼性を維持するものになります。
VDCエコシステムにおいて、OktaとAuth0はどこに位置するのでしょうか？
ユーザーの年齢、雇用状況、または認定ステータスを確認する必要がある新しいアプリを構築していると想像してください。紙の上では単純に聞こえますが、実際には、ばらばらの標準、複数の認証情報形式、デジタルIDと物理IDの両方をナビゲートするのは圧倒される可能性があります。
これは、OktaとAuth0が真の価値を提供するところです。当社のプラットフォームは、アサーションの作成、他のアイデンティティプロバイダーからのアサーションの消費、およびほぼすべてのアプリケーションにアイデンティティを統合するためのSDKとライブラリの提供という、主要なアイデンティティ機能をすでに処理しています。
VDCの検証および発行機能を提供することで、開発者向けの実装を簡素化し、複雑に絡み合った標準スタックを抽象化します。これにより、VDCが将来のデジタルアイデンティティのためのシームレスで再利用可能な構成要素になるための基盤が築かれます。
私たちは、この新しいコア機能を将来のためのシームレスな構成要素にする基盤を構築しています。専門的な資格やスマートヘルスカードのような、より複雑または長期的なユースケースでは、当社のツールは、開発者、管理者、および消費者が安全かつセキュアにコミュニティを構築およびサポートするのに役立ちます。
詳細を確認し、VDCの動作を確認するには、oktacredentials.devをご覧ください。
