本コラムでは、前回記載したVerifiable Credential（VC）のMicrosoft版である、Microsoft Entra IDの具体的な動作や、サンプルアプリによる検証結果を記載していこうと思います。まずは、前回のおさらいからスタートします。
前回のおさらい
前回のコラムでは、Verifiable Credential（VC）の機能や使いどころ（ユースケース）について、お話しさせていただきました。詳細は「Microsoft Entra Verified IDとは」をご覧いただきたいと思うのですが、VCは「不必要な個人情報の開示制限」や「参照先のコスト軽減」を背景に、
- •DIDアイデンティティ（利用者自身）に属性情報を紐づける
- •紐づけた属性情報を第三者が証明できる（デジタル証明書ベース）
- •提示する属性情報を「個人情報の選択的最小開示」で制限できる
といった基本機能を持っており、利用者自身がVCを管理（発行依頼や提示）するモデルとなっている特徴があります。
VC情報が記載されたDIDドキュメントは信頼システム（Verifiable Data Registryの一部）に登録され、参照可能（webサーバー）であること、VC発行者（Issuer）と確認者（Verifier）を別組織にすることで、参照の負荷軽減や改ざんの防止、利用目的の隠蔽化が図れるオペレーションで確認が行われます。
Microsoft Entra Verified IDは、VCの発行者（Issuer）および確認者（Verifier）の役割を行うSaaSサービスになります。どちらの役割も利用可能ですが、前提として信頼システムにDIDドキュメントの保存先をドメイン登録（webサーバーFQDN）しておく必要があります。
VC発行の流れ
VC発行時の流れについては、Microsoftの資料で確認ができます。Microsoft Entra 確認済み ID の発行ソリューションを計画する - Microsoft Entra Verified ID | Microsoft Learnをご覧ください。詳細は複雑なため、この資料を読んでいただくことをお奨めしますが、各コンポーネントは、事前にご理解いただいた方がいいかもしれません。
以下、一部引用となります。
出典：https://learn.microsoft.com/ja-jp/entra/verified-id/plan-issuance-solution
- •発行者のビジネスロジック
VC情報の参照・抽出の仕組みを提供します。わかりやすいのはMicrosoft Entra IDといったIdPからの属性提供等ですが、発行モデルによっては独自のデータ提供が行われる場合もあります。 - •発行者のWebフロントエンド
VC発行の要求やデータのやり取りのインターフェースを提供するWebアプリです。Issuerが用意します。ビジネスロジックの取り込みやEntra Verified IDへの要求が行われます。 - •ウォレット
VCを格納するデバイスとソフトウェアです。スマートフォンにインストールされたMicrosoft Authenticatorなどが対象です。 - •Azureサービス
実際のVC発行を行うクラウドサービスです。以下2つとなります。- ◦Key Vault
VCの作成や署名に必要な「シークレット」を提供します。シークレットを使って発行されたVCはウォレットに格納されます。 - ◦Entra Verified ID
VCの発行や検証を行うSaaSサービスです。WebフロントエンドはREST APIを使用して要求操作を行いますが、以後はウォレットが直接通信を行います。発行に必要なVCのビジュアル（表示定義）や属性構成（ルール）を合わせて定義します。Entra IDテナントに1つだけ定義できます。
- ◦Key Vault
- •信頼システム
利用者のDIDドキュメントの格納先を提供します。DID:Webの場合は信頼されたIssuerのWebサーバーが指定されます。
基本的な動作としては、以下の通りです。
- 1.Webフロントエンドがビジネスロジックを取り込んだうえ、VC発行要求のための二次元コードを示す
- 2.ウォレットが二次元コードにアクセスしEntra Verified IDにVCを要求する
- 3.Entra Verified IDはKey Vaultのシークレットを使ってVCを署名し発行を行う
- 4.VCがウォレットに格納されWebフロントエンドに発行結果が戻される
より詳細なシーケンスについては、フロー 1: 検証可能な資格情報の発行を参照いただくとわかりやすいでしょう。
VC検証の流れ
VC検証時の流れについても、Microsoftの資料で確認ができます。Microsoft Entra Verified ID 検証ソリューションを計画する - Microsoft Entra Verified ID | Microsoft Learnをご覧ください。詳細は複雑なため、この資料を読んでいただくことをお奨めしますが、各コンポーネントは、事前にご理解いただいた方がいいかもしれません。
以下、一部引用となります。
出典：https://learn.microsoft.com/ja-jp/entra/verified-id/plan-verification-solution
- •RPのWebフロントエンド
VC検証の要求やデータのやり取りのインターフェースを提供するWebアプリです。Verifierが用意します。VCの提示をビジネスロジックに反映します。 - •RPのビジネスロジック
VC検証が成功した後に「何をさせたいか」を定義したロジックを指します。（たとえば）「VCを持っているユーザーだけ割引を行う」といった動作です。 - •ウォレット
VCを格納するMicrosoft Authenticatorです。Web Clientとあるのはユーザーが検証時に使用する「ネイティブWebアプリ」のことです。手元のスマホアプリで行うのか、Webブラウザーで行うのかの差だけになります。 - •発行者に信頼されたVC
ウォレットから提供される信頼済みVCです。わかりやすいようウォレットから独立して書かれています。 - •Azureサービス
実際のVC検証を行うクラウドサービスです。以下2つとなります。- ◦Key Vault
VCの検証に必要な「検証ツールキー」を提供します。検証ツールにはVCの署名、更新、回復に使用される 1つのキーセットがあります。 - ◦Entra Verified ID
VCの発行や検証を行うSaaSサービスです。WebフロントエンドはREST APIを使用して要求操作を行いますが、以後はウォレットが直接通信を行います。（信頼システムにある）Verifier DIDを提供するインターフェースとして機能します。
- ◦Key Vault
- •信頼システム
利用者のDIDドキュメントの格納先を提供します。DID:Webの場合は信頼されたVerifierのWebサーバーが指定されます。
基本的な動作としては、以下の通りです。
- 1.Webフロントエンドが、VC提示要求のための二次元コードを示す
- 2.ウォレットが二次元コードにアクセスしEntra Verified IDにVC提示要求する
- 3.Entra Verified IDはVC提示要求をウォレットに示しダウンロードされる
- 4.ウォレットは提示要求に合致するVCおよびDIDをウォレット内で検索し決定する（手動）
- 5.決定されたVCをRPと共有するため、VC等をEntra Verified IDに送信する
- 6.Entra Verified ID はVCが共有された結果をWebフロントエンドに通知する
- 7.検証されたVCに基づき、ビジネスロジックを発効させる
より詳細なシーケンスについては、フロー 2: 検証可能な資格情報の提示を参照いただくとわかりやすいでしょう。
なお、ここでいう「VC提示要求」とは信頼済みVCに求める属性や条件の定義、RPのDIDが含まれます。RP側が「対象となるVCの条件」と「自分自身のDID」を提示することで、ウォレットに格納されたVCに合致するものがあるか、DIDは正当なものかどうか、を利用者は確認できることになります。
集中型IDアーキテクチャと分散型IDアーキテクチャ
今までのお話は「分散型IDアーキテクチャ」についてでしたが、「集中的IDアーキテクチャ」という概念も存在します。
分散型IDアーキテクチャとは、IDの主体は（ウォレットを持つ）個人が中心となり、それぞれの組織が限定的に「IDに関する操作」を行うことで、情報提示や組織間の連携性を分散するしくみです。
一方、集中的IDアーキテクチャとは、端的にいうと「IdPを中心とした旧来の認証認可・フェデレーション」を指しています。通常のビジネスロジックでは、企業が管理するIdPの情報がベースとなるため、企業人としての属性や権限については、企業が（IdPを通して）一括提供できます。（ユーザー体験: 信頼境界内にあるリソースへのアクセスを参照のこと）
しかしこの文脈では、「個人が保有している属性」を企業が確認したい場合、適切に機能しません。たとえば「公的資格（仕業等）」や「ベンダー資格」は利用者個人に属するもので、内容によっては「更新・失効」などの確認が都度必要なためです。
このようなケースで、個人に属する資格確認の部分だけVCで実装することで、集中的ID機能はそのままで利用ができます。詳細については、信頼境界内での VC の使用を確認いただくと、わかりやすいと思います。この例では、「特定の研修の完了を示すVC」や、「自社社員であることを示すVC」をあらかじめ所有しておくことで、必要な追加業務作業が行える、というものです。これも一つのユースケースとなるでしょう。
ユースケースモデル
Microsoftが想定しているモデル（それは今回検証してみるモデルとかぶっているのですが）としては、以下2つになります。
雇用/メンバーシップの証明
VC発行は「自企業Entra IDテナント」のユーザーを基に行います。自企業テナントに記載されたユーザーは「従業員」である、という前提で、発行者が保証します。VCが発行されると、そのVCがMicrosoft Authenticatorに保存されます。
VC検証は外部企業からの照会が前提です。VCから従業員であることが確認できれば、たとえばディスカウントされた値段の商品が表示されます。いわゆるB2Bサービスを想定したモデルといえます。
出典：https://learn.microsoft.com/ja-jp/entra/verified-id/plan-issuance-solution
本人確認
VC発行は「Webアプリが提出を求めた」独自情報を基に行います。前提としてWebアプリにアップロード機能があり、アップロードされた情報（たとえばパスポート情報と顔写真）に紐づく「本人確認」について、発行者が保証します。VCが発行されると、そのVCがMicrosoft Authenticatorに保存されます。
VC検証は任意の団体からの照会となります。VCから本人確認が取れると、本人性が前提となるプライベートサービスにアクセスできます。B2Cサービスを想定したモデルといえます。
出典：https://learn.microsoft.com/ja-jp/entra/verified-id/plan-issuance-solution
次回は実際の検証に入っていきます。まずは、Entra IDテナントを直接設定していく「従業員証明」のVC発行を通じて、Entra Verified IDの基本操作を確認する予定です。ご期待ください。
- ※文中の商品名、会社名、団体名は、一般に各社の商標または登録商標です。