Microsoft Entra 確認済み ID のアーキテクチャの概要
資格情報の発行や検証に加えて、アーキテクチャとビジネスに対するソリューションの影響が完全にわかるように、検証可能な資格情報ソリューションを計画することが重要です。 まだ確認していない場合は、Microsoft Entra 確認済み ID の概要と FAQ に関する記事を確認してから、概要のチュートリアルを完了することをお勧めします。
このアーキテクチャの概要では、Microsoft Entra 確認済み ID サービスの機能とコンポーネントについて説明します。 発行と検証の詳細については、以下を参照してください。
ID に対するアプローチ
今日のほとんどの組織では、集中型 ID システムを使用して従業員の資格情報を提供しています。 また、さまざまな方法を使用して、顧客、パートナー、ベンダー、証明書利用者を組織の信頼境界に取り込んでいます。 このような方法としては、フェデレーション、Microsoft Entra B2B などのシステムによるゲスト アカウントの作成と管理、証明書利用者との明示的な信頼の作成などがあります。 ほとんどのビジネス関係にはデジタル コンポーネントがあるため、組織間で何らかの形式の信頼を実現するには、多大な労力が必要です。
集中型 ID システム
集中型アプローチは、アプリケーション、サービス、デバイスがドメインまたは信頼境界内で使用される信頼メカニズムに依存している場合など、多くのケースで引き続き適切に機能します。
集中型 ID システムでは、ID プロバイダー (IDP) によって資格情報のライフサイクルと使用が制御されます。
ただし、検証可能な資格情報で分散型アーキテクチャを使用すると、次のような主要なシナリオを拡張することで価値を提供できる場合があります
リモート シナリオを含め、従業員や他のユーザーの ID の安全なオンボード。
特定の条件に基づく、組織の信頼境界内のリソースへのアクセス。
組織によって発行された移植可能な資格情報による、パートナーのリソースへのアクセスなどの、信頼境界外のリソースへのアクセス。
分散型 ID システム
分散型 ID システムでは、資格情報のライフサイクルと使用の制御は、発行者、所有者、および資格情報を使用する証明書利用者の間で共有されます。
たとえば、次の図のようなシナリオについて考えてみましょう。eコマース Web サイトの Proseware が、Woodgrove の従業員に社内割引を提供しようとしています。
検証可能な資格情報 (VC) に慣れていない場合、VC の用語は混乱を招く可能性があります。 次の定義は、Verifiable Credentials Data Model 1.0 の用語セクションのものです。 それぞれの後で、それらを前の図のエンティティに関連付けます。
"issuer (発行者) は、1 人以上の対象者に関するクレームをアサートし、これらのクレームから検証可能な資格情報を作成して、検証可能な資格情報を所有者に送信することによって、エンティティが実行できる役割です。"
- 前の図では、Woodgrove が従業員に対する検証可能な資格情報の発行者です。
"holder (所有者) は、1 つ以上の検証可能な資格情報を所有し、そこから提示を生成することで、エンティティが実行できる役割です。 所持者とは、通常は (そうでない場合もありますが) 自分が所持している検証可能な資格情報の対象者です。 所有者は、資格情報を資格情報リポジトリに格納します。"
- 上の図では、Alice は Woodgrove の従業員です。 Woodgrove の発行者から取得した検証可能な資格情報の所有者です。
"verifier (検証者) は、エンティティが 1 つ以上の検証可能な資格情報を受け取って実行する役割です (必要に応じて、処理のための検証可能な提示内で)。 他の仕様では、この概念を証明書利用者と見なす場合があります。"
- 上の図では、Proseware は Woodgrove によって発行された資格情報の検証者です。
"credential (資格情報) は、発行者によって行われた 1 つ以上のクレームのセットです。 検証可能な資格情報は、暗号論的に検証可能な作成者を持つ改ざんの跡がすぐ分かる資格情報です。 検証可能な資格情報を使用して、検証可能な提示を作成でき、それは暗号論的に検証することもできます。 資格情報内のクレームは、異なる対象者に関すものである場合があります。"
"decentralized identifier (分散型識別子) は、エンティティに関連付けられた移植可能な URI ベースの識別子です (DID とも呼ばれます)。 これらの識別子は、検証可能な資格情報で使用されることがよくあり、対象者、発行者、検証者に関連付けられます。"
"decentralized identifier document (分散型識別子ドキュメント) は、DID document (DID ドキュメント) とも呼ばれ、検証可能なデータ レジストリを使用してアクセスできるドキュメントであり、関連するリポジトリや公開キー情報など、特定の分散型識別子に関連する情報が含まれています。"
このシナリオにおいては、発行者と検証者の両方が DID を持ち、DID ドキュメントを持っています。 DID ドキュメントには、公開キーと、DID に関連付けられている DNS Web ドメイン (リンク ドメインとも呼ばれます) の一覧が含まれます。
Woodgrove (発行者) は、従業員の VC に秘密キーを使って署名します。同様に、Proseware (検証者) は、そのキーを使って VC を提示する要求に署名します。これは DID にも関連付けられます。
"信頼システム" は、分散システム間の信頼を確立するための基盤となります。 分散型の台帳にすることも、DID Web などの集中型の台帳にすることもできます。
"distributed ledger (分散型台帳) とは、イベント記録用の非集中化システムです。 これらのシステムにより、参加者が運用上の決定を行うために他のユーザーによって記録されたデータに依存するのに十分な信頼が確立されます。 通常、異なるノードがコンセンサス プロトコルを使用して暗号化署名されたトランザクションの順序を確認する分散データベースを使用します。 時間が経過すると、デジタル署名されたトランザクションのリンクにより、台帳の履歴が実質的に変更できなくなることがよくあります。"
集中型 ID アーキテクチャと分散型 ID アーキテクチャの組み合わせ
検証可能な資格情報ソリューションを調べる場合は、分散型 ID アーキテクチャと集中型 ID アーキテクチャの組み合わせにより、リスクが軽減され、運用上の大きな利点があるソリューションが提供される方法を理解すると役に立ちます。
ユーザー体験
このアーキテクチャの概要では、組織による採用に応募して受け入れる求職者と従業員の体験に従います。 その後、検証可能な資格情報によって周遊型プロセスを強化できる従業員と組織の変化を追います。
これらのユース ケースのアクター
Alice: Woodgrove, Inc の採用に申し込んで受け入れる人。
Woodgrove, Inc: 架空の会社。
Adatum: Woodgrove の架空の ID 検証パートナー。
Proseware: Woodgrove の架空のパートナー組織。
Woodgrove は集中型 ID アーキテクチャと分散型 ID アーキテクチャの両方を使用しています。
ユーザー体験の手順
Alice による Woodgrove, Inc の職の申し込み、受け入れ、オンボードし。
Woodgrove の信頼境界内のデジタル リソースへのアクセス。
Woodgrove またはパートナーの信頼境界を拡張することのない、Woodgrove の信頼境界の外部にあるデジタル リソースへのアクセス。
Woodgrove はビジネスを続けるに当たり、ID を継続的に管理する必要があります。 このガイダンスのユース ケースでは、Alice がセルフサービス機能を使用して識別子を取得および管理する方法と、Woodgrove がさまざまな信頼要件を持つ企業間リレーションシップを追加、変更、終了する方法について説明します。
これらのユース ケースでは、集中型 ID と分散型 ID を組み合わせて、より堅牢で効率的な ID と信頼の戦略とライフサイクルを提供する方法を示します。
ユーザー体験: Woodgrove へのオンボード
認識: Alice は Woodgrove, Inc. での仕事に関心を持ち、Woodgrove のキャリア Web サイトにアクセスします。
アクティブ化: Woodgrove サイトでは、信頼できる ID 証明パートナーである Adatum にアクセスするための QR コードまたはディープ リンクを使用して、ID を証明する方法が Alice に提示されます。
要求とアップロード: Adatum は Alice に ID 証明を要求します。 Alice は、セルフィと運転免許証の写真を撮影し、Adatum にアップロードします。
発行: Adatum は、Alice の ID を検証すると、Alice に ID を証明する検証可能な資格情報 (VC) を発行します。
提示: Alice (資格情報の所有者と対象者) は、Woodgrove のキャリア ポータルにアクセスして、申し込みプロセスを完了できます。 Alice が VC を使用してポータルにアクセスすると、Woodgrove は検証者と証明書利用者の役割を担い、Adatum からの構成証明を信頼します。
初期資格情報の配布
Alice は Woodgrove での雇用を受け入れます。 オンボード プロセスの一環として、Alice が Woodgrove の信頼境界内で使用するための Microsoft Entra アカウントが作成されます。 Alice のマネージャーは、リモートで働く Alice が、安全な方法で初期サインイン情報を受け取る方法を理解する必要があります。 かつては、IT 部門がそれらの資格情報をマネージャーに提供し、マネージャーはそれらを印刷して Alice に渡しました。 資格情報を印刷する方法は、遠隔地で働く従業員に対しては有効に機能しません。
VC を使用すると、資格情報の配布プロセスを強化することで、集中型システムに価値を追加できます。 管理者が資格情報を提供する代わりに、Alice は、ID の証明として VC を使用して、集中型システム アクセス用の初期ユーザー名と資格情報を受け取ることができます。 Alice は、オンボード プロセスの一環として、ウォレットに追加された ID の証明を提示します。
オンボードのユース ケースでは、発行者、検証者、所有者の間に信頼関係の役割が分散されます。
発行者は、発行する VC の一部であるクレームを検証する責任を負います。 Adatum は Alice の ID を検証して VC を発行します。 この場合、検証者または証明書利用者を考慮せずに、VC が発行されます。
所有者は VC を所有し、検証のために VC の提示を開始します。 Alice が保持している VC を提示できるのは Alice のみです。
検証者は、信頼する発行者からの VC のクレームを受け入れ、検証可能な資格情報データ モデルで説明されている分散型台帳機能を使用して VC を検証します。 Woodgrove は、Alice の ID に関する Adatum のクレームを信頼します。
オンボード用に集中型と分散型の ID アーキテクチャを組み合わせることで、ID 検証に必要な Alice に関する特定の人しか知らない情報 (政府機関 ID 番号など) を Woodgrove が格納する必要はありません。これは、ID 検証パートナー (Adatum) によって発行された Alice の VC によって ID が確認されることを、Woodgrove が信頼しているからです。 作業の重複は最小限に抑えられ、初期オンボード タスクに対するプログラムによる予測可能なアプローチを実装できます。
ユーザー体験: 信頼境界内にあるリソースへのアクセス
従業員である Alice は、Woodgrove の信頼境界内で働いています。 Woodgrove は ID プロバイダー (IDP) として機能し、Alice が Woodgrove の信頼境界内で対話するために使用するアプリの ID と構成を完全に制御します。 Microsoft Entra ID の信頼境界内のリソースを使用するには、Alice は、複数の形式である可能性がある ID の証明を提供して Woodgrove の信頼境界にサインインし、Woodgrove のテクノロジ環境内のリソースにアクセスします。 複数の証拠に基づく方法は、集中型 ID アーキテクチャを使って効果的に提供される一般的なシナリオです。
Woodgrove は信頼境界を管理し、優れたセキュリティ プラクティスを使用して、実行される仕事に基づいて Alice に最小特権レベルのアクセスを提供します。 強力なセキュリティ体制を維持するとめと、場合によってはコンプライアンス上の理由から、Woodgrove は従業員のアクセス許可とリソースへのアクセスを追跡できる必要があり、雇用が終了したらアクセス許可を取り消すことができる必要があります。
Alice は、Woodgrove が Woodgrove のリソースにアクセスするために保持している資格情報のみを使用します。 Alice は資格情報がいつ使われるかを追跡把握しておく必要はありません。資格情報が Woodgrove によって管理され、Woodgrove のリソースのみに関して使われるからです。 ID は Woodgrove のリソースへのアクセスが必要なときに Woodgrove の信頼境界内でのみ有効なので、Alice は資格情報を所有する必要はありません。
信頼境界内での VC の使用
個々の従業員の ID ニーズは変化しており、VC はそれらの変化を管理するために集中型システムを拡張できます。
Woodgrove によって雇用されていますが、Alice には特定の要件を満たすためにリソースへのアクセス権を取得する必要がある場合があります。 たとえば、Alice がプライバシー トレーニングを完了すると、そのクレームで新しい従業員 VC を発行されることができ、その VC を使用して制限付きリソースにアクセスできます。
VC は、アカウントの回復のために信頼境界内で使用できます。 たとえば、従業員が電話とコンピューターを紛失したときは、Woodgrove によって信頼されている ID 検証サービスから新しい VC を取得してアクセスを回復し、その VC を使用して新しい資格情報を取得することができます。
ユーザー体験: 外部リソースへのアクセス
Woodgrove は、Proseware と製品購入割引を交渉します。 Woodgrove のすべての従業員が割引の対象となります。 Woodgrove は、Proseware の Web サイトにアクセスし、購入した製品の割引を受ける方法を、Alice に提供したいと考えています。 Woodgrove で集中型 ID アーキテクチャが使用されている場合、Alice に割引を提供するには 2 つの方法があります。
Alice は個人情報を提供して Proseware でアカウントを作成することができ、Proseware は Woodgrove での Alice の雇用を確認する必要があります。
Woodgrove は証明書利用者として Proseware を含むように信頼境界を拡張することができ、Alice は拡張された信頼境界を使用して割引を受けることができます。
分散型識別子を使用すると、Woodgrove は検証可能な資格情報 (VC) を Alice に提供することができ、Alice はそれを使用して Proseware の Web サイトや他の外部リソースにアクセスできます。
Alice に VC を提供することで、Woodgrove は Alice が従業員であるという構成証明を行っています。 Woodgrove は、Proseware の検証ソリューションの信頼できる VC 発行者です。 Woodgrove の発行プロセスにおけるこの信頼により、Proseware は Alice が Woodgrove の従業員である証拠として VC を電子的に受け入れ、Alice に割引を提供することができます。 Proseware は、Alice が提示する VC の検証の一環として、信頼システムを使用して VC の有効性を確認します。 このソリューションの内容:
Woodgrove は、信頼境界を拡張することなく、Alice が Proseware に雇用証明を提供できるようにします。
Proseware は、Alice が Woodgrove の従業員であることを検証するために、信頼境界を拡張する必要はありません。 Proseware では、Woodgrove が提供する VC を代わりに使用できます。 信頼境界が拡張されないので、信頼関係の管理が容易になり、Proseware は VC をそれ以上受け入れないことで、関係を簡単に終了できます。
Alice は、メール アドレスなどの Proseware での個人情報を提供する必要はありません。 Alice は、個人デバイスのウォレット アプリケーションで VC を保持します。 その VC を使用できるのは Alice だけであり、Alice は資格情報の使用を開始する必要があります。 VC が使われると、その事実が毎回ウォレット アプリケーションによって記録されるため、Alice は、VC がいつどこで使われたかの記録を持っています。
Woodgrove では、集中型と分散型の ID アーキテクチャを組み合わせて信頼境界の内側と外側での運用に対応することで、複雑さとリスクを軽減し、限定的な関係を簡単に管理できるようにしています。
時間経過に伴う変化
Woodgrove では、他の組織との新しいビジネス関係の追加や、既存の関係の終了が発生するため、集中型と分散型の ID アーキテクチャをどのような場合に使用するか判断する必要があります。
集中型と分散型の ID アーキテクチャを組み合わせることで、ID 自体と ID の証拠に関連する責任や手間は分散され、リスクも分散されます。 ユーザーは、頻繁に、または多数の、未知の検証者に対して自分の個人情報を開示するリスクを負わなくて済みます。 具体的には、次のように使用します。
- 集中型 ID アーキテクチャでは、IDP が資格情報を発行し、それらの発行された資格情報の検証を実行します。 IDP は、すべての ID に関する情報を処理し、 ディレクトリへの格納、またはディレクトリからの取得を行います。 また、IDP は、他の IDP システム (ソーシャル サインインやビジネス パートナーなど) から提供されるセキュリティ トークンを動的に受け入れることができます。 証明書利用者が IDP の信頼境界内の ID を使用するには、IDP によって発行されたトークンを受け入れるように構成されている必要があります。
分散型 ID システムのしくみ
分散型 ID アーキテクチャでは、発行者、ユーザー、証明書利用者 (RP) はそれぞれ、互いの資格情報の継続的な信頼できる交換を確立し、確保する役割を持っています。 アクターの DID の公開キーは信頼システムを介して解決でき、それにより、署名の検証と、検証可能な資格情報を含む任意の成果物の信頼が可能になります。 証明書利用者は、発行者との信頼関係を確立することなく、検証可能な資格情報を使用できます。 代わりに、発行者は、証明書利用者に証明として提示する資格情報を、対象者に提供します。 アクター間のすべてのメッセージは、アクターの DID を使用して署名されます。発行者と検証者からの DID も、要求を生成した DNS ドメインを所有する必要があります。
たとえば、VC 所有者がリソースにアクセスする必要があるときは、その証明書利用者に VC を提示する必要があります。 これを行うには、ウォレット アプリケーションを使用して、VC を提示する RP の要求を読み取ります。 要求を読み取る処理の中で、ウォレット アプリケーションは信頼システムを使用し、RP の DID によって RP の公開キーを検索します。これにより、VC の提示要求が改ざんされたものでないかを検証します。 また、ドメインの所有権を証明するために、ウォレットは、RP の DNS ドメイン内にホストされているメタデータ ドキュメントからその DID が参照されていることを確認します。
フロー 1: 検証可能な資格情報の発行
このフローでは、次の図で示すように、資格情報の所有者が発行者と対話して、検証可能な資格情報を要求します
所有者は、ブラウザーまたはネイティブ アプリケーションを使用してフローを開始し、発行者の Web フロントエンドにアクセスします。 そこでは、発行者の Web サイトによってユーザーのデータ収集が行われ、発行者固有のロジックが実行されて、資格情報を発行できるかどうかと、その内容が決定されます。
発行者の Web フロントエンドによって、Microsoft Entra 確認済み ID サービスが呼び出されて、VC 発行要求が生成されます。
Web フロントエンドによって、QR コードまたはデバイス固有のディープ リンクとして (デバイスによって異なります)、要求へのリンクが提供されます。
所有者は、Microsoft Authenticator などのウォレット アプリを使用して、ステップ 3 の QR コードまたはディープ リンクをスキャンします
ウォレットにより、リンクから要求がダウンロードされます。 要求には次のものが含まれます。
発行者の DID。 ウォレット アプリが信頼システムを介して解決を行い、公開キーおよびリンクされたドメインを検索する際には、発行者の DID が使用されます。
VC マニフェストの URL。VC を発行するためのコントラクト要件が指定されています。 コントラクト要件には、id_token と、提示が必須とされる自己構成証明属性、または、別の VC を提示することが含まれる場合があります。
VC の外観 (ロゴ ファイルの URL、色など)。
ウォレットによって発行要求が検証され、コントラクトの要件が処理されます。
発行要求メッセージに、信頼システムで解決された DID ドキュメント内にある発行者のキーによる署名が付与されているかの検証が行われます。 署名の検証は、メッセージが改ざんされていないことの保証となります。
発行者の DID ドキュメントで参照されている DNS ドメインの所有権が、発行者に帰属しているかの検証が行われます。
VC のコントラクト要件によっては、ウォレットによって所有者に追加情報の収集が要求される場合があります。たとえば、自己発行の属性の要求や、OIDC フロー内の移動による id_token の取得などです。
コントラクトに必要な成果物が Microsoft Entra 確認済み ID サービスに送信されます。 Microsoft Entra 確認済み ID サービスから発行者の DID キーで署名された VC が返され、ウォレットによって VC は安全に格納されます。
発行ソリューションを構築する方法とアーキテクチャに関する考慮事項の詳細については、「Microsoft Entra 確認済み ID 発行ソリューションを計画する」を参照してください。
フロー 2: 検証可能な資格情報の提示
このフローでは、所有者は証明書利用者 (RP) と対話し、承認要件の一部として VC を提示します。
所有者は、ブラウザーまたはネイティブ アプリケーションを使用してフローを開始し、証明書利用者の Web フロントエンドにアクセスします。
Web フロントエンドによって、Microsoft Entra 確認済み ID サービスが呼び出されて、VC 提示要求が生成されます。
Web フロントエンドによって、QR コードまたはデバイス固有のディープ リンクとして (デバイスによって異なります)、要求へのリンクが提供されます。
所有者は、Microsoft Authenticator などのウォレット アプリを使用して、ステップ 3 の QR コードまたはディープ リンクをスキャンします
ウォレットにより、リンクから要求がダウンロードされます。 要求には次のものが含まれます。
スキーマまたは資格情報の種類の資格情報に対する標準ベースの要求。
RP の DID。ウォレットによって信頼システムで調べられます。
ウォレットにより、提示要求が検証され、格納されている VC で要求を満たすものが検索されます。 必要な VC に基づいて、ウォレットにより対象者は VC の使用を選択して同意するようにガイドされます。
- サブジェクトは、VC を RP と共有することを同意します
その後、ウォレットにより、対象者によって署名された提示応答ペイロードが Microsoft Entra 確認済み ID サービスに送信されます。 その構成要素を次に示します。
対象者が同意した VC。
サブジェクト DID。
ペイロードの "対象ユーザー" としての RP DID。
Microsoft Entra 確認済み ID サービスにより、ウォレットによって送信された応答が検証されます。 VC は、場合によっては VC 発行者によって失効させられている可能性があります。 検証者は、VC がまだ有効であることを確認するために、VC 発行者への照会を行う必要があります。 この手順の詳細は、手順 2 で検証者による VC 要求がどのように行われたかによって異なります。
検証時に、Microsoft Entra 確認済み ID サービスによって結果と共に RP がコールバックされます。
検証ソリューションを構築する方法とアーキテクチャに関する考慮事項の詳細については、「Microsoft Entra 確認済み ID 検証ソリューションを計画する」を参照してください。
重要なポイント
分散型アーキテクチャを使用すると、既存のソリューションを拡張し、新しい機能を提供できます。
検証可能な資格情報ソリューションを作成する際は、Decentralized Identity Foundation (DIF) と W3C の設計目標の要求を実現するために、以下の事項を考慮する必要があります。
システム内のアクター間に信頼関係を確立する中心点はありません。 つまり、アクターは特定の VC を信頼しているため、信頼境界はフェデレーションを通して拡張されません。
- 信頼システムにより、アクターの分散化識別子 (DID) を検出できます。
ソリューションにより、検証者は任意の発行者からの検証可能な資格情報 (VC) を検証できます。
ソリューションでは、発行者が対象者または検証 (証明書利用者) の承認を制御することはできません。
アクターは切り離された方法で動作し、それぞれが自分の役割のタスクを完了できます。
発行者はすべての VC 要求を処理し、サービスされる要求を区別することはありません。
対象者は発行された VC を所有し、VC を任意の検証者に提示できます。
検証者は、任意の対象者または発行者からの任意の VC を検証できます。
次のステップ
検証可能な資格情報のアーキテクチャについてさらに学習します