Microsoft Entra Verified IDとは
Microsoft Entra Verified IDとは、「分散化ID（DID）」に基づく、個人アイデンティティにかかわるデジタル証明書の管理運用のしくみ全般をフォーカスしています。狭い意味（製品としてのフォーカス）は個人情報を保護するかたちで発行されたデジタル証明書を指していますが、実態としてはそのしくみ全般を理解しておくことが、重要です。
なお、DIDやVCの定義はすそ野が広く網羅的な記述は難しいです。したがって適宜内容を省略していること、個人の見解が含まれている点には、ご留意いただければと思います。
DIDの必要性とは
IDentityにおけるDIDの必要性については、よく「ポイントカード」にたとえられます。特定企業がサービス利用に応じて発行する金券ですが、その利用には一般に、
- •本人が「本人である」ことの確認
- •本人が「ポイントカードの利用資格」を持つことの確認
の2つが必要になります。「本人である」ことについては、公的な身分証明書をポイントカード作成時に提示し（一般には）ポイントカード用データベースに登録されます。作成時には、
- •身分証明書が本物であること
- •写真と本人の比較で同一人物であること
- •初回提出時の情報（住所氏名等）が身分証明書と一致していること
- •初回提出時の情報（登録条件等）が要件を満たすこと
が対面でチェックされ、デジタル登録されます。登録条件とは、たとえば「18歳以上の成人である」とか「現住所がサービス提供範囲内（店舗と同一）である」など、約定に依存する事柄です。
以後は利用時にカード本体を見せることでサービスを受けるわけですが、「提出者が利用者本人である」ことは都度確認されません。実際の金券ではないので「不正があっても損害が少ない」のと、都度本人確認を行うのは高コストになるからです。契約内容の変更など、必要時に身分証の再提示や登録内容の復唱（本人しか知りえないということになっている）で、再度本人性を確認します。
デジタルの世界では、自身の「本人性を表す」情報全般をアイデンティティと呼びます。IDやパスワードということではなく、自分自身を表す属性（氏名・住所・年齢等）や経歴（職務・資格・免許等）を持った、本人自身を指します。属性や経歴は頻繁にアップデートが行われること、データコピーによる複製で詐称が容易にできてしまうことから、「本人であること」と「情報の正しさ」を都度確認する必要があります。
「正しさ」の確認は、発行元への照会が基本です。本人確認なら政府の照会機関、民間（社歴や在籍）ならば組織ごとに用意された照会機関が該当します。実際に存在するかはひとまず置いて、これを用意した場合、以下の問題が発生します。
- •機器障害による確認遅延や管理コストの増大
- •「名寄せ」の危険性
遅延やコストの問題は物量としての話ですが、名寄せについてはプライベート情報の流出に関する話となります。名寄せとは銀行の用語で「自行内の同一顧客の資産情報を統合する」ことですが、現在では、複数の断片情報を組みあわせ「特定個人のプライベート情報を再構成する」という意味で使われるケースが多いです。SNSなどで散見され、「断片化した情報が誰でも確認できる」状況と「組み合わせのノウハウ」知識があれば、できてしまうことが恐ろしいです。
アイデンティティ情報の「一部を保持する」機関＝政府や業界企業連合など、利益を同じくする機関の間で情報共有を行った場合、照会情報の突合などで、名寄せが成ってしまい、本来不必要な個人情報の把握や管理ができるようになってしまう可能性は、ないかあるかといえば、ある、ということになってしまいます。名寄せの危険性を排することは、プライベート情報保護の観点で必要ですし、結果論としてデジタル化の敷居が下がることにもつながると思います。
ちなみに、意図的に行わなくても「名寄せが成ってしまう」ケースが存在します。デジタルプラットフォーマーの存在です。Facebook、Googleなど、認証連携を基盤としたプラットフォーマーは、さまざまなサービスに対してIdP機能を公開しています。技術的には素晴らしいのですが、ユーザーが利用するサービスが理論的には名寄せできてしまうこと、万一IdPサービスが終了してしまった場合、利用者リスクが著しく高くなってしまいます。特定のデジタルプラットフォーマーへの依存度を下げる、という効果も期待されている、と個人的には理解しています。
デジタル証明書の照会履歴を「発行者自身が把握しない」こと、デジタル証明書の正当性を発行者自身のリソースに頼らず24時間365日で参照可能な状況にする、この2つの目的を叶えるために、提供した情報や本人性が正しいことを「第三者に証明」してもらうしくみを備えたものが「Verifiable Credential（VC）」となります。VCには以下の機能があります。
- •DIDアイデンティティに属性情報を紐づける
- •紐づけた属性情報を第三者が証明できる（デジタル証明書）
- •提示する属性情報を制限する「個人情報の選択的最小開示」ができる
詳細については、政府から発行されている以下の資料などを、まずはご確認ください。該当資料に古い内容が含まれている点は、ご留意ください。
Verifiable Credentials 及び Decentralized Identifiers の概要
Verifiable Credential（VC）モデルとは
Verifiable Credential（VC）のMicrosoft版がMicrosoft Entra Verified IDになります。
一般に「検証可能な資格証明」と訳されますが、役割をMicrosoft資料で図示化すると、以下のようになります。
- •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にも関連付けられます。
- •Trust System（信頼システム）※筆者注：Verifiable Data Registryを含む
分散システム間の信頼を確立するための基盤となります。分散型の台帳にすることも、DID Webなどの集中型の台帳にすることもできます。 - •distributed ledger（分散型台帳）
イベント記録用の非集中化システムです。これらのシステムにより、参加者が運用上の決定を行うために他のユーザーによって記録されたデータに依存するのに十分な信頼が確立されます。通常、異なるノードがコンセンサスプロトコルを使用して暗号化署名されたトランザクションの順序を確認する分散データベースを使用します。時間が経過すると、デジタル署名されたトランザクションのリンクにより、台帳の履歴が実質的に変更できなくなることがよくあります。
Microsoftからの引用となってしまいましたが、ポイントとしては、以下の点になるかと思います。
- •Issuerの役割は以下の通り。
- ◦公的機関・企業体など「資格を承認」する組織が対象
- ◦Verified Credentialsを発行し、HolderにVCを提供する
- ◦HolderにVCを提供した際作成した「DID Document」をVerifiable Data Registryに公開する
- •Holderの役割は以下の通り。
- ◦自身が作成したDIDに紐づく「承認された資格を保有」する個人が対象
- ◦DIDに紐づく発行済みVCを必要に応じて提示する
- ◦どのVCを提示するかは、自身で決定・行動する。VCのカスタマイズを発行要求することで、一部分に限定した個人情報を提示できる
- •Verifierの役割は以下の通り。
- ◦「承認された資格を前提」に利用可能なサービス
- ◦所定の情報+取得済みのVCを提示することで、提供するサービス等の利用手続きを進められる
- ◦提示されたVCの正当性をVerifiable Data Registryに公開されたDID Documentから確認するが、Issuerには直接確認しない
- •Trust System（Verifiable Data Registryを含む）の役割は以下の通り。
- ◦Issuerとは異なる信頼された第三者組織（IDentity Verification Partner）が対象
- ◦Verifierが確認するべき要件（VCの発行履歴が正当かどうか）をIssuerに代わって提供する
ここで重要なのは、Holder=アイデンティティ主体者が中心となってアイデンティティ情報の提供やコントロールが行えるモデルになっているということ、IssuerはHolderのVC使用目的（Verifierのサービスを使うこと）を知らない、ということです。
アイデンティティ主体者が自分自身で、提供する個人情報属性をコントロールすることを、自己主権型アイデンティティ管理（Self-Sovereign Identity：SSI）と呼びます。DIDモデルで最初に実現されるべき要件です。
HolderのVC利用目的をIssuerに知らせない、ということは、結果論として名寄せの防止につながります。同時にIssuerが照会機関を自分で管理運用するコストを軽減できます。理論的にはIDentity Verification Partnerが結託して名寄せをする、ということも懸念されますが、IDentity Verification Partnerはこの事業を行うためだけの専業業者が前提で、名寄せによるビジネス的うまみは得にくい、という解釈になっているようです。
distributed ledger（分散型台帳）はDIDによく出てくる用語です。先の説明の通り、分散配置されたデータベースで、一か所の情報が追加されると他データベースの情報も同様に更新されるしくみです。「ブロックチェーン」という改ざん防止技術が使われることがあるため、組みで紹介されることが多いですが、必須技術ではありません。ですので、分散型台帳＝ブロックチェーンという括りは、技術的には当を得ていないと思います。
ブロックチェーンの強みは、ブロック単位でデータを追加し、前ブロックのデータ（ハッシュ値等）を基に自ブロックのデータを連結する（チェーン）ことで、後からの改ざんが難しい、という技術的優位性に依ります。改ざんが行われてチェーンが棄損した場合、ルールに基づき正しい内容で上書きされる、ということのようです。
ブロックチェーンは現状広く一般化はしていませんが、一因として「大規模展開しないと問題がある」セキュリティ仕様を含むため、実際に検討すると非常に高コストになるためと思われます。小規模の場合、高可用性が難しいのは当然として、「51%攻撃」という手法で、実質ブロックチェーン情報の書き換えができてしまう、という問題があるということです。以下の資料に非常に的確にまとまっていますので、参考にしていただければと思います。
ブロックチェーンは改ざんできる？できない理由や仕組み・基礎知識をご紹介！ | パーソルクロステクノロジー株式会社
いっぽう集中型の台帳というものも存在しています。先に紹介されたDID:Web技術ですが、特定のWebサーバーをVerifiable Data Registryとして登録し、そこにDID Documentを配置します。構成がシンプルで、圧倒的に費用が掛からないため、エンタープライズ環境だと、こちらを採用しているケースも多いと思われます。
Microsoft Entra Verified IDのコンポーネント
上記のモデルを踏まえ、Microsoft Entra Verified IDのしくみになぞらえると以下のようになります。
出典：https://learn.microsoft.com/ja-jp/entra/verified-id/decentralized-identifier-overview
- 1.W3C 分散化識別子（DID）
一切の組織または政府から独立してユーザーが作成、所有、管理するID。DIDは、公開キーマテリアル、認証記述子、サービスエンドポイントを含むJSONドキュメントで構成された分散公開キーインフラストラクチャ（DPKI）メタデータにリンクされたグローバル一意識別子です。 - 2.信頼システム
DIDドキュメントを解決できるようにするために、DIDは通常、信頼システムを表す何らかの種類の基になるネットワークに記録されます。Microsoftは現在、DID:Web信頼システムをサポートしています。DID:Webは、Webドメインの既存の評判を使用して信頼を許可するアクセス許可ベースのモデルです。DID:Webは全般利用可能なサポート状態です。 - 3.DID ユーザーエージェント/ウォレット：Microsoft Authenticatorアプリ
現実のユーザーが分散化IDと検証可能な資格情報を使用できるようにします。Microsoft Authenticatorは、DIDを作成し、検証可能な資格情報の発行とプレゼンテーション要求を容易にし、暗号化されたウォレット ファイルを介してDIDのシードのバックアップを管理します。 - 4.Microsoftリゾルバー
did:webメソッドを使ってDIDを検索して解決し、DIDドキュメント オブジェクト（DDO）を返すAPI。DDOには、公開キーやサービス エンドポイントなど、DIDに関連付けられたDPKIメタデータが含まれています。 - 5.Microsoft Entra検証済みIDサービス
メソッドを使用して署名されるdid:web向けのAzureの発行および検証サービスとREST API。これらにより、ID所有者によるクレームの生成、表示、検証が可能になります。このサービスは、システムのユーザー間の信頼の基礎を形成します。
用語の説明については前述を参考いただくとして、ここでの読み解きは以下になると思います。
まず信頼システム（Verifiable Data Registryを含む）に関しては、DID:Webつまり集中型の台帳の利用を前提としていることです。Entra Verified IDがプレビューだった時代にはDID:Ion（Microsoftが主導するビットコイン系分散型台帳）も利用可能だったのですが、2023年12月で機能が削除されたため、現状明確にサポートしているのはDID:Webのみということは覚えておくといいかと思います。
次に「Microsoftリゾルバー」の存在です。DIDメソッドはDIDやDIDメタデータを名前解決して、最終的にDID Documentを取得するプロセスを定義します。メソッド間では特段の連携機能はないため、メソッドをまたぐ名前解決の必要性から、名前解決機能を（汎用的な）関数として外出ししてあるのが、リゾルバーです。Universal Resolverなどが有名ですが、Microsoftも自身でリゾルバーを提供しています。Microsoftが主導しているDID:Ionにも対応している強みがあります。（現在ではUniversal Resolverでも解決可能になっています）
Microsoft Entra Verified IDはSaaSサービスとして提供されています。Issuerが使用する「VC発行機能」とVerifierが使用する「VC検証機能」の両方を提供します。利用サービスは同じですが、IssuerとVerifierの接点は当然ありませんので、セキュリティ的に問題はない、理解となります。
VCのユースケース
Verifiable Credentialsのユースケースについては、現在ではさまざまな内容について、個別の検証がなされ、報告例が少なくありません。報告された内容がデジタル庁から公開されていたりします。
Verifiable Credential (VC/VDC) の活用におけるガバナンスに関する有識者会議（第1回）｜デジタル庁
【資料2】DID/VC共創コンソーシアム提出資料
上記の例では、金融機関の介在を前提とした「本人が真正であること」「本人が特定の属性を保有していること（保有していないこと）」を保証するVCの提供を受け、事業者が必要なサービスを提供する、というモデルになっています。
- •一般企業のマネーロンダリングチェック簡便化
利用者（Holder）は取引銀行等（Issuer）から、あらかじめ取引モニタリングやスクリーニングの結果が良好であることの確認を受けます。この確認をVC化して、同様の確認が必要なクレジット会社（Verifier）へのローン申請等での手続きを簡略化します。必要なVCは以下の通りです。- ◦マイナンバーカード検証済みVC（本人確認）
- ◦スクリーニング検証済みVC（取引内容確認）
- •電子レシートのマストバイキャンペーンへの活用
利用者（Holder）は小売・飲食サービス店舗と提携する電子レシート事業者（Issuer）から、キャンペーン応募への条件となる商品の電子レシートをVCとして受け取ります。VC化された電子レシートを提示しキャンペーンに応募できますが、このとき「選択的開示」としてレシートでの対象商品のみを提示できます。これで一緒に購入した商品リストを知られることはありません。必要なVCは以下の通りです。- ◦電子レシート検証済みVC（応募条件確認）
- ◦マイナンバーカード検証済みVC（本人確認）
- •ライブチケット転売対策
利用者（Holder）は金融機関等（Issuer）から、本人確認を受けVCを取得します。チケットはこのVCの提示で購入することで、少なくとも反社会勢力への販売をフィルターできます（金融機関はこの情報を持っているため）。入場時までに生体認証の確認を受けたVCも取得しておき、実際の入場時に生体認証VCを検証できれば、その場で生体認証を行ったのと同様の結果が得られることになります。必要なVCは以下の通りです。- ◦本人確認検証済みVC（本人確認と反社属性確認）
- ◦生体認証検証済みVC（生体確認）
注：現場スタッフによる生体VC検証の負担が重いといった課題に注意する必要があります。
- •法人格の財務諸表の証明支援
法人格利用者（Holder）は税理士（Issuer）から、財務諸表の内容が適切であることを確認したVCの発行を受けます。このVCを取引先銀行に提示することで適正な内容であることを証明できます。同様にクレジットカード事業者に提示することで、事業者の与信確認業務を簡略化できます。必要なVCは以下の通りです。- ◦財務諸表検証済みVC（税理士による内容確認）
上記は金融機関からの提案だったため、このような内容になっていますが、VCのしくみに適う事業であればさまざまな業種で利用可能なものだと思います。探してみましたら、以下に詳細にまとめられた情報もありましたので、ご紹介させていただきます。詳細は資料を直接、ご参照ください。
分散型アイデンティティのユースケース（Verifiable Credentials） #W3C - Qiita
今回、私自身の知識のブラッシュアップもかねて、ひとまず概要とユースケースを語らせていただきましたが、次回はMicrosoft Verified IDのチュートリアル環境に準拠するかたちで、検証作業と結果をご報告できれば、と思っております。
- ※文中の商品名、会社名、団体名は、一般に各社の商標または登録商標です。