「Microsoft Entra Verified ID」とは？ 分散型IDの基礎とユーザーメリット

銀行での口座開設や自治体の証書発行などの際に求められる「本人確認」。これまでは、ユーザーの身元情報を渡して本人であることを証明していたが、分散型IDをベースとするMicrosoft Entra Verified IDはこれをどう変えるのか。

[土肥正弘，ドキュメント工房]

　「Microsoft Entra」とは、Microsoft のID管理3ツール「Microsoft Azure AD」（以下、Azure AD）「Microsoft Entra Permissions Management」「Microsoft Entra Verified ID」（以下、Entra Verified ID）をまとめたリブランド製品で、プライバシー保護とIDガバナンスの強化を目的としたものだ。中でも次世代ID管理「分散型ID管理」と関連の深いEntra Verified IDは、まだユーザーに理解されていない部分が多い。Microsoft Entraリリース当時に富士榮（ふじえ） 尚寛氏（OpenIDファウンデーションジャパン代表理事）が開催したオンラインセミナーの内容を基に、Microsoft EntraとEntra Verified IDの概要を解説する。

本稿は、富士榮 尚寛氏によるオンラインセミナーの一部を抜粋し、編集部で再構成した。

「分散型」と「従来型」ID基盤の違い、ユーザーと企業のメリット

　Microsoft Entraを知るには、まず「分散型ID」を理解する必要がある。

　オフラインサービスのオンラインシフトが進む中で、本人確認つまり「会ったことのない相手をどうやって信頼するか」が課題となる。現在、われわれはIDプロバイダーやサービス事業者に自分の身元情報の一部及び全てを渡してサービスを利用している。つまり、プロバイダーやサービス事業者がユーザーの身元情報をコントロールできる状態にあるということだ。これに対して、IDを自分自身でコントロールする「自己主権型アイデンティティー」を可能にするのが「分散型ID」だ。

　ぞれにはIDを検証する仕組みが必要になる。その技術要素として求められるのは、分散型識別子（Decentralized Identifiers：DID）と検証可能な属性情報（Verifiable Credentials：VC）だ。

図1　インターネット利用でのID課題と分散IDの技術要素（出典：オンラインセミナーで投影の資料）

　DIDは分散台帳で管理される識別子で、VCは分散型識別子と関連付けされた公開鍵で検証可能な属性情報だ。これらはスマートフォンやNFC（近距離無線通信）チップなどに入れて持ち運ぶことができ、ユーザーがサービス事業者に提示する情報を自分で選択して使い分けることが可能になる。分散型IDのイメージと特長を物理世界や従来のID管理と比較したのが図2だ。

図2　物理世界、従来のデジタル世界、分散型IDの特徴（出典：オンラインセミナーで投影の資料）

　分散型IDの価値は「IDプロバイダーへの依存度を下げる」ことにある。ユーザーにとってはIDプロバイダーが落ちてもサービスを継続して利用でき、事業者目線にとってはIDプロバイダーの可用性要件を下げられる継続的なID管理が不要になるという利点がある。

図3　ID基盤のパラダイム変化（出典：オンラインセミナーで投影の資料）

　分散型IDは「情報管理はしたくないが、ID発行事業者として身元保証はしたい」「ID発行事業者に知られることなくサービスを利用したい」といったニーズに応えるものだ。主な利用シーンとメリットについて、以下が考えられる。

• サプライチェーンのID管理：企業への所属証明やアクセス権限証明、OEM企業のID管理やパスワード管理の手間を省ける
• 顧客や自治体における個人ID管理：SNSを使った簡易ID登録と身元保証の両立、事業者への依存度低減、年齢などの身元確認（公的な身分証明の電子化）が容易になる
• 従業員や学生のID管理：入社、入学時の身元確認（公的な身分証明の電子化、パスワードレス化、オンラインでのアカウント払い出しなど）に利用できる

Microsoft の「Entra Verified ID」とは

　Microsoft Entraとは、分散化IDの資格情報の作成と発行、確認を行う本人確認ソリューションだ。冒頭で説明した通り3つのコンポーネントをまとめたもので、Permissions ManagementはMicrosoftは先ごろ買収した「CloudKnox Permissions Management」（「Google Cloud」「Amazon Web Services」「Microsoft Azure」のIM管理を一元化するもの）を、Entra Verified IDは旧Azure AD Verifiable Cledentialsをリブランドしたものだ。

　Entra Verified IDはそれ単体で動作するものではなく、キーコンテナ（Key Vault）と、ストレージアカウントとWebサーバ、Azure ADへのアプリ登録とAPIへのアクセス許可が必要だ。ここからは、Entra Verified IDの設定について説明する。Microsoftの公式ドキュメントと併せて確認するといいだろう。

「組織名」「ドメイン」「キーコンテナ」の設定

　「組織名」にはID発行元の組織名を設定する。「ドメイン」は、Verified IDの所有権を確認するための設定ファイル（Webサーバの「.well-Known/did-configuration.json」ファイル）を置くドメイン名を設定する。「キーコンテナ」は、資格情報に署名するための鍵を保存できる場所を設定する。

図4　Entra Verified IDの設定画面例（出典：オンラインセミナーで投影の資料）

代替信頼システム（DIDメソッド）の設定

　DIDメソッドとして何を使うかを設定する。「did:web」と「did:ion」の2つが選択可能だ。did:webが規定のメソッドだが、分散台帳の仕組みを用いずにWebで識別する方法になっていて、厳密には分散型IDとは異なる。一方のdid:ionはブロックチェーンベースの分散型IDネットワーク「ION」（Identity Overlay Network：アイオン）を利用するものだ。

ドメインの検証

　ドメインの検証はWebサーバに配置された「did-configuration.json」で所有権を検証する。did:ionの場合はIONネットワークにDID Documentが浸透するまでに1〜2時間程度かかるので注意が必要だ。

資格情報の定義

　次にVCを定義する。資格情報の一意の識別子である「資格情報名」を設定し、表示の定義、ルールの定義をJSONで記述する。VCはスマホに発行されるが、Microsoftの実装では「Microsoft Authenticator」を使う。またルールの定義では、発行する資格情報の元となる属性取得先や資格情報の有効期間などが定義できる。

資格情報の発行

　定義された資格情報を発行するにはIssuance APIを実行する。これはAzure ADに登録したアプリケーションの権限で実行するものになり、Issuance APIを使う発行用のWebアプリの開発が必要だ。OpenID for Verifiable Credential Issuanceの使用にのっとったやりとりが行われる。

　現在はこの方法のみだが、Azure ADのグループ単位で資格情報をプッシュ通知する仕組みを現在準備中だという（本稿公開時点）。

図5　スマホへの資格情報の発行（ウォレットへの追加）のイメージ（出典：オンラインセミナーで投影の資料）

資格情報の検証

　資格情報の発行の考え方と同じく、ここではPresentation APIを実行する。提示されたVCの情報を指定されたURLに送り、OpenID for Verifiable Presentationにのっとって検証が行われる。

　以上のように、Entra Verified IDはIONを利用することでブロックチェーンで分散型IDを運用可能にするところが大きなポイントだ。今後の拡張が期待できるツールであり、さまざまなソリューションに応用可能と考えられている。新たな本人確認の仕組みとして、今後期待を集めるかもしれない。