SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

Microsoft Entra Verified IDの紹介

大場 正隆

はじめに

Microsoft Entra Verified IDは、Azure Active Directory (Azure AD) を利用した分散化IDシステムです。
これは、ブロックチェーン技術や分散型台帳技術(DLT)に基づいたセキュアなデジタルIDを提供し、個人や組織の身元確認を可能にします。

デジタルIDには大きく4つの特徴があります。
  1. セキュリティ: 暗号化やデジタル署名を使用して、情報の改ざんや盗難から保護されます。
  2. プライバシー: 必要最低限の情報しか共有されず、個人情報が適切に管理されます。
  3. 自己主権: ユーザー自身が、誰とどの情報を共有するかをコントロールできます。
  4. 信頼性: 信頼できる発行者や検証者からの証明書や資格を受け取ることができます。

また、3つの要素で構成されています。
  1. 発行者(Issuer): 証明書や資格を発行する機関です。
  2. 主体(Subject): 資格を持つ個人や組織です。
  3. 検証者(Verifier): 資格を確認するための第三者です。

よくあるケースを紹介します。例えば、大学がデジタルIDの発行者となるケースです。大学(発行者)が卒業証明書をデジタルIDとして発行します。このデジタルIDを卒業生(主体)に渡され、雇用者(検証者)がこれを検証します。雇用者(検証者)は、その卒業証明書が信頼できる大学(発行者)から発行されていることを確認できます。

ちなみに、デジタルIDについては、こちらのテックブログにわかりやすく記載されております。ぜひお読みください。
次世代のID ~自己主権型アイデンティティ(SSI)とDIDs~

Microsoft Entra Verified IDでは、これらのことを実現するためのものであり、個人情報のセキュリティとプライバシーを保護しながら、身元確認を容易に構築するソリューションです。
Microsoft Entra Verified IDを使用することで、発行者である企業や組織はデジタルIDの発行をし、その証明をしたい検証者はその身元を簡単に検証を行うことができるようになります。

Verified IDを使用してIDの発行と検証をしてみる

以下のようなことをやっていきたいと思います。今回使用するサンプルアプリケーションは一つで確認済みIDの取得と検証をします。本来は発行者(Issuer)、検証者(Verifier)で用意する必要があります。

Microsoft Entra Verified IDの準備

準備には以下を実施します。
  1. キーコンテナを作成・設定
  2. 確認済みIDの設定(組織の設定)
  3. AzureADのアプリを登録
  4.  ※この「アプリ」というのは、言葉が混在してしまってわかりづらいですが、AzureADを使うための設定作業になります。
  5. 確認済みIDの設定(分散化 ID を登録、ドメインの所有権を確認)
VerifiedIDは2023年6月14日現在Azureポータル上「確認済みID」と表示されておりますので、便宜上、準備と検証では確認済みIDと呼ぶことにします。
上記の準備でAzureAD設定作業が伴うことから、AzureADの設定作業ができる強い権限(管理者)が必要となります。また、KeyvalutやVerifiedIDを作成するための権限が必要になります。
そのため、実務で構築する場合は管理者権限で設定をしていくため注意が必要です。

それでは、実際に触ってみましょう。

1.キーコンテナを作成・設定

確認済み ID サービスでは、公開キーと秘密キーが Azure Key Vault に格納されます。 これらのキーは、資格情報の署名と検証に使用されます。

まずは、キーコンテナを作成します。作成したキーコンテナで[設定] の [アクセス ポリシー] を選択し、[アクセス ポリシーの追加] の [ユーザー] で、使用するアカウントを選択し、[編集]を選択します。

[キーのアクセス許可] で、 [作成] 、 [削除] 、 [署名] のアクセス許可が選択されていることを確認します。 既定では、 [作成] と [削除] は既に有効になっていますので、 更新する必要があるキーのアクセス許可は、 [署名] のみを追加し、保存します。


2.確認済みIDの設定(組織の設定)

次に「確認済みID」へ移動します。
左側のメニューSetupを選び、[Define organization settings]のUpdateを押します。




Organization nameを入力し、発行者となるTrusted domainを入力します。次の確認済みIDの設定作業にて、このドメインにファイルを配置する必要があるため、個人でやる場合はそれ用に準備する必要があります。キーコンテナーはKeyvaultで先ほど作ったものを選択します。


3.AzureADのアプリケーションを登録

アプリケーションで確認済みIDの資格情報を発行または検証できるように、 確認済み IDのAPI を呼び出す必要があるときに、アクセス トークンを取得する必要があります。 アクセス トークンを取得するには、AzureADのアプリケーションを登録し、確認済み ID 要求サービスに対する API アクセス許可を付与する必要があります。


AzureADのアプリケーションを登録したら、APIのアクセス許可を設定します。この設定をすることで、確認済み IDへアクセスすることが可能になります。

APIのアクセス許可から「規定のディレクトリに管理の同意を与えます」をしたあとに「アクセス許可の追加」をします。



APIアクセス許可の要求で「所属する組織で使用しているAPI」タグにし、Verifiable Credentials Service Requestを選びます。



アプリケーションの許可を選び、「VerifiableCredential.Create.All」にチェックを入れ、アクセス許可を追加します。


アプリケーション検証のために、作成したクライアントIDとテナントIDを記録し、シークレットの作成とシークレットも記録しておきます。

クライアントIDとテナントIDはアプリの概要でみることができます。



シークレットは証明書とシークレットから作ることができます。
シークレットは作成したら、そのシークレット値を記録します。作成時しか表示されないのと取り扱いには気を付けてください。

また、シークレットは有効期限があり、ポータル画面上では2年までが最大の期限になりますので、注意ください。


4.確認済みIDの設定(分散化 ID を登録、ドメインの所有権を確認)

「確認済みID」の画面に戻ります。
次のステップである分散化IDを登録します。

画面に従い、JSONファイルをダウンロードし、先ほど設定したドメインのサーバにJSONファイルをアップロードします。



アップロードすると、状態が登録済みに変わります。


画面のステップに従って、次はドメインの所有権の確認です。こちらもJSONファイルを取得し、サーバにアップロードします。



このステップも終わると、確認済みIDの画面がすべてチェック済になります。


以上で下準備は完了です。

確認済み ID の資格情報を発行する

資格情報を発行するために、まずは確認済み資格情報カードを作成します。

確認済みIDの資格情報から作ります。


[Custom Credential] (カスタム資格情報) を選び、JSON形式でカードの表示やルールを定義することが可能です。


表示は、以下のような書き方で定義することができます。
{
	    "locale": "en-US",
	    "card": {
	      "title": "Verified Credential Expert",
	      "issuedBy": "Microsoft",
	      "backgroundColor": "#000000",
	      "textColor": "#ffffff",
	      "logo": {
	        "uri": "https://didcustomerplayground.blob.core.windows.net/public/VerifiedCredentialExpert_icon.png",
	        "description": "Verified Credential Expert Logo"
	      },
	      "description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
	    },
	    "consent": {
	      "title": "Do you want to get your Verified Credential?",
	      "instructions": "Sign in with your account to get your card."
	    },
	    "claims": [
	      {
	        "claim": "vc.credentialSubject.firstName",
	        "label": "First name",
	        "type": "String"
	      },
	      {
	        "claim": "vc.credentialSubject.lastName",
	        "label": "Last name",
	        "type": "String"
	      }
	    ]
	}

ルールは、以下のような書き方で定義することができます。
	{
	  "attestations": {
	    "idTokenHints": [
	      {
	        "mapping": [
	          {
	            "outputClaim": "firstName",
	            "required": true,
	            "inputClaim": "$.given_name",
	            "indexed": false
	          },
	          {
	            "outputClaim": "lastName",
	            "required": true,
	            "inputClaim": "$.family_name",
	            "indexed": false
	          }
	        ],
	        "required": false
	      }
	    ]
	  },
	  "validityInterval": 2592000,
	  "vc": {
	    "type": [
	      "VerifiedCredentialExpert"
	    ]
	  }
	}


作成できると以下のように表示されます。




資格情報の発行でauthorityとmanifestは検証用アプリケーションのために記録します。


今回の検証では、マイクロソフトが用意しているサンプル用アプリケーションを使います。
対象のアプリは.NET5になっているので開発環境にない方はインストールが必要になります。

appsettings.jsonに以下を記載します。
  1. Tenant ID: AzureADのテナント ID
  2. Client ID: AzureADのクライアント ID
  3. Client Secret: AzureADのクライアント シークレット
  4. IssuerAuthority: 確認済みIDの分散化識別子(authority)
  5. VerifierAuthority: 確認済みIDの分散化識別子(authority)
  6. Credential Manifest: 確認済みIDのマニフェスト URL(manifest)
このサンプルコードでは「IssuerController.cs」で主体(Subject)情報を変更することができます。ここでは私の名前(Oba Masataka)を入れてみます。

本来であれば、ちゃんとした認証フローを経たうえで取得した主体(Subject)情報が入ります。
	                //here you could change the payload manifest and change the firstname and lastname
	                if ( payload.ContainsKey("claims") )
	                {
	                    if ( ((JObject)payload["claims"]).ContainsKey("given_name") )
	                    {
	                        payload["claims"]["given_name"] = "Masataka";
	                    }
	                    if (((JObject)payload["claims"]).ContainsKey("family_name"))
	                    {
	                        payload["claims"]["family_name"] = "Oba";
	                    }
	                }
	


サンプルアプリケーションを起動します。
	cd active-directory-verifiable-credentials-dotnet/1-asp-net-core-api-idtokenhint
	dotnet build "AspNetCoreVerifiableCredentials.csproj" -c Debug -o .\\bin\\Debug\\netcoreapp3.
	dotnet run
	


ngrok というツールを使ってポート番号5000 に URL を設定し、インターネット上で一般公開します。
※ngorkは一時的にネットワーク内部にあるローカルサーバのポート(ローカルホスト)に外部から直接アクセスすることを可能にするトンネリング/リバース・プロキシツールです。利用には個人責任でお願いします。

ngrokはサインアップしたあと、トークンをコマンドでセットする必要があります。
	ngrok config add-authtoken トークン名
	ngrok http 5000
	

ForwardingのURLをブラウザで表示させます。


VisitSiteをクリックします。


ここまでが発行者(Issuer)側の作業です。これ以降、視点は主体(Subject)になります。

サンプルアプリケーションの画面です。GET CREDENTIALを選択します。

ここではサンプルアプリケーションでの確認であり、実際には発行者(Issuer)側が用意したユーザーのログインなどの承認フローがあったうえでの発行になります。



QRコードが表示されますので、主体(Subject)のAuthenticator アプリで QR コードをスキャンします。
以下アプリでコードを読み取った後の画面です。




検証済みID(アプリとポータルとで日本名が異なっています)として登録されました。


カード情報を表示し、確認することができます。先ほど「IssuerController.cs」で主体(Subject)情報を入れた内容がこちらにも反映されています。


以上で確認済みIDの資格情報を発行することができました。

上記の方法はあくまで検証のために一貫して確認しておりましたが、Authenticator アプリで QR コードで確認済みIDの登録は本来主体(Subject)が行います。


確認済み ID の資格情報を検証する

次に確認済みIDの資格情報を検証してみます。こちらもAuthenticator アプリで QR コードで確認済みIDの検証は主体(Subject)が行うものです。

今度はVERIFY CREDENTIALを選択します。
ここでもサンプルアプリケーションの話であり、本来検証するための機構は検証者(Verifier)が用意するものです。


QRコードが表示されますので、Authenticator アプリで QR コードをスキャンします。 以下アプリでコードを読み取った後の画面です。



共有を押すと、要求は承認されたと表示されます。


アクティビティとして履歴が残ります。


アプリケーション画面では検証結果が表示されました。


以上、確認済みIDを検証してみました。

今までやったことを簡単にフローにしてみました。証明書の発行・検証もわかりやすいフローなのと、サンプルアプリ的にも認証周りを触ったことがある方は比較的に簡単に構築することができそうでした。

ReactとSpringbootが出ておりますが、今回のサンプルでは使用しておりません!

これからのMicrosoft Entra Verified ID

以上簡単ではありますが、Microsoft Entra Verified IDを触ってみました。

Microsoft Entra Verified IDは最近機能強化が盛んに行われております。
Microsoft Entra Verified IDとMicrosoft Entra Identity Governanceが統合、LinkedInメンバーがEntra Verified IDを使って職場を確認できる社員IDを発行することもできるようになりました。今後ますますオンボーディングの場面にも活躍されていきそうですし、他のシーンでも活用できそうです。

またMicrosoft Entra Verified ID digital wallet SDKが2023年6月にGA予定であったりと、昨年2022年8月にMicrosoft Entra Verified IDがGAされてからどんどん拡がりをみせています。

今後発行者(Issuer)がさらに拡がり、デジタルIDが活発化、それと同時に、Microsoft Entra Verified IDも使われていくと思われます。非常に面白い分野なので、今後もキャッチアップしていきたいです。


参考文献

Microsoft Entra Verified ID のドキュメント – Microsoft Entra