今なら間に合う分散型IDとEntra Verified ID
•
7 likes•12,155 views
6/30のOffice365勉強会のEntra Verified ID特集の資料です。 分散型ID、Entra Verified IDの解説をしています。
Report
Share
今なら間に合う分散型IDとEntra Verified ID
- 1. 今なら間に合う 分散型ID ＆ Entra Verified ID 2022/06/30 富⼠榮 尚寛 @phr_eidentity
- 2. 自己紹介 役割/活動 • OpenIDファウンデーション・ジャパン代表理事、KYC WG設立 • 米国OpenID Foundation eKYC and Identity Assurance WG, co-chair • 色々と委員（ISO、某官房、某研究所など） • 某SIerでビジネス開発 書き物など • Blog：IdM実験室（https://idmlab.eidentity.jp） • 監訳 : クラウド時代の認証基盤 Azure Active Directory 完全解説 • 共著 : クラウド環境におけるアイデンティティ管理ガイドライン その他活動 • 日本ネットワークセキュリティ協会アイデンティティ管理WG • Microsoft MVP for Enterprise Mobility（Jan 2010 -） • LINE API Expert （Feb 2018 -） • Auth0 Ambassador（Sep 2018 -）
- 3. 本日のネタ • 分散型IDとは？ • なんで必要？ • コンセプトは？ • 何ができる？ • 何に使える？ • Entra Verified IDとは？ • どんなもの？ • 使い方は？ ※なるべく深いところまで掘り下げず、まんべんなく語るよう努力！
- 5. ID領域における未解決問題 • アイデンティティ保証 • 誰がその属性を発行・保証しているのか？ • 発行主体が無くなったらどうするのか？ • 否認/アカウント停止（中央集権からのネグレクト） • なりすまし防止 • O2O Binding（本人確認）、安全なID連携 • プライバシー保護 • IDを握った企業が行動履歴を掌握 • 事業者間の名寄せによるプライバシー侵害
- 6. ID領域における未解決問題 • アイデンティティ保証 • 誰がその属性を発行・保証しているのか？ • 発行主体が無くなったらどうするのか？ • 否認/アカウント停止（中央集権からのネグレクト） • なりすまし防止 • O2O Binding（本人確認）、安全なID連携 • プライバシー保護 • IDを握った企業が行動履歴を掌握 • 事業者間の名寄せによるプライバシー侵害 属性発行元が無くなっても 真正性を証明する方法 ID情報を 安全に伝える方法 IDプロバイダに行動履歴を 把握されない方法
- 7. 必要な要素と分散型IDにかかる技術要素 属性発行元が無くなっても 真正性を証明する方法 ID情報を 安全に伝える方法 IDプロバイダに行動履歴を 把握されない方法 自己主権型アイデンティティ （Self Sovereign Identity – SSI） 分散型識別子 （Decentralized Identifiers – DID） 検証可能な属性情報 （Verifiable Credentials – VC） 技術要素 コンセプト
- 8. 分散型ID – 関連キーワードの整理 ž 自己主権型アイデンティティ（Self Sovereign Identity） ž 分散型識別子（Decentralized Identifiers） ž 検証可能な属性情報（Verifiable Credentials）
- 10. 自己主権型アイデンティティ（SSI） ž Sovrin foundationの定義 ž 自己主権型アイデンティティ（SSI）とは「個人は、管理主体が介在することなく、自身のア イデンティティを所有しコントロールできるべきである」、と考えるデジタル・ムーブメン トを表す言葉である。SSIを使うと、人々は現実世界で彼らが行っているのと同じ自由度と信 頼性をもってデジタル世界でも活動することが出来る。（https://sovrin.org/faq/what-is-self- sovereign-identity/） ž インテンション・エコノミー（Doc Searls / 2012） ž 顧客の意思に基づく経済（VRM）の実現 ž 企業が顧客の関心（アテンション）を中心に行う経済活動（CRM）と対局 ž 顧客が企業に自分自身の意思を持ってアイデンティティ情報を提供することで、 ž 企業がBig Dataをもとに推測したリコメンド・広告表示による気持ち悪さからの脱却 ž 企業が大量データを収集・分析を行うためのコストの削減 いつの間にか「アイデンティティの所有」の話になってきている？？
- 19. 自分の意思を持ってアイデンティティ情報を提供 ž 利用者目線で必要なこと→ポータブルであること ž 事業者になるべく依存せず（例：IdPが落ちていたり、IdPによってBANされることなく）自 身の属性情報をサービス提供者へ選択的に開示 ž 一方でサービス事業者目線では→高度な信頼 ž 提供された属性情報を信頼できること（事業者の介在なく提供された情報への信頼） ž 「No trust, more truth」に通じる？「Trust, but verify（信じよ、されど確認せよ）」 ※信頼とは？ 事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い （内閣官房/Trusted Web推進協議会の定義より）
- 20. 信頼のDXの要が「DID、VC」 ポータブル ⾼度な信頼 従来のデジタルID 物理世界のID 分散型ID （DID/VC） ポイント 利⽤者の意思で、 • いつでも使える • 使い分けができる （持ち運べること） • スマホ、NFCチップ等に IDを⼊れて持ち運ぶ • 提⽰属性の選択・使い分 けができる 中⼼となる技術要素 • 分散台帳上で管理される分散型識別⼦（Decentralized Identifiers / DID） • 分散型識別⼦と関連付けされた公開鍵で検証可能な属性情報（Verifiable Credentials / VC） • 財布に⼊れて免許証、社 員証などを持ち運ぶ • 使い分けができる • IDシステム状態に依存す る（システム停⽌、アカ ウント停⽌等） • 提⽰情報の使い分けは難 しい（利⽤者の意思は反 映されにくい） 受取った側が、 • 真贋判別が出来る （検証可能であること） • 分散台帳上の公開鍵を使 い、ID発⾏元への問い合 わせせずに検証可能（永 続性の担保、事業者依存 からの脱却） • IDシステムでユーザ認証 して検証する（認証強度 によりID漏洩の危険性） • IDシステム状態に依存す る（システム停⽌等） • 対⾯で表情などを含め総 合的に判断 • 勘と経験で免許証の真贋 を判断 ID漏洩、プライバシ問題 対⾯前提、勘と経験 真のDXの要として注⽬
- 21. 分散型識別子（DID/Decentralized Identifiers） ž 特定の事業者に依存しない識別子（Identifier） ž Identity（属性の集合）ではなく、Identifier（識別子） ž W3Cにより標準化（did:method:xxxx） ž DIDと紐づく鍵ペアを生成、秘密鍵へのアクセス＝「所有」 ž 識別子に紐づくDID Documentが分散台帳上等で公開される ž DIDに紐づく秘密鍵で署名したデータをDID Document上の公開鍵で検証する ことでDIDの「持ち主」が発行したデータであることを検証できる（VCはこ の仕組みを利用） ž 事業者の都合（倒産やアカBANなど）で公開鍵の取り消しや改竄ができない ため、自己主権っぽく見える（そのためにはPermissionlessなチェーンが望ま しいが実態は・・・）
- 22. 何が分散 ž 系の分散：特定の系への依存度を下げる（ソーシャルログオンと同レベル） ž 系の中でのノード分散：系を運営する事業者への依存度を下げる（本質） 基盤レイヤ データレイヤ APIレイヤ sovrin bitcoin ethereum ION（sidetree） N N … N N N … N N N … N ・・・ did:sov:xxx did:btcr:xxx did:ion:xxx did:eth:xxx ・・・ Discovery Service（Universal resolver等） driver driver driver driver ・・・
- 23. ざっくり言うと ž 各エンティティがメソッド単位で鍵ペアに紐づくDIDを取得する ž メソッド（ionとかbtcrとかethrとか）ごとのノードの運営が特定事業者に限定されないので、 少なくとも識別子の単位で勝手に消されたり、公開されるDID Documentが改ざんされる恐れ は少ない＝分散、事業者非依存、SSIというキーワードへ繋がっている ž よくある質問 ž メソッドを跨いでDIDを引っ越すことはできる？ ž できません。SSIと言いつつメソッドの系への依存はします。 ž DID Documentを分散台帳へ記録するためのコストは誰が負担するの？ ž 系によってまちまちです。Sovrin foundationだとFoundationへの参加した組織だけが書き込めて、トランザクショ ンごとに費用が発生していたはず。 ž 鍵のローテーションはどうする？ ž DID Documentの更新（公開鍵の追加）を行います。過去の秘密鍵で署名されたVCは過去の公開鍵で検証ができる ので、少なくとも当該のDIDを管理しているエンティティにより署名された過去があることはわかります。
- 24. 検証可能な属性情報（VC/Verifiable Credentials） ž 検証可能なデータモデル ž 発行者（Issuer）のDIDに紐づく秘密鍵によりデジタル署名される ž 発行者のDID Documentに含まれる公開鍵を使って検証可能 ž エンティティ間でのトランスポートはW3C定義外。ここはOIDC4VCやDIDCommの範囲 分散台帳（DID Documentを配置） ⾏政/キャリア/企業 など 個⼈のID Wallet アプリケーション VP: Verifiable Presentation VCを複数束ねたもの
- 25. メリット ž Issuerの事業継続性を気にする必要がない（OIDCとの対比で言うと、IdPがなく てもRPがid_tokenの検証ができる）⇒過去のVCを検証可能、疎結合でOK ž 複数Issuerから発行されたVCをまとめて提示可能 分散台帳（公開鍵基盤） 個⼈のID Wallet アプリケーション
- 26. ざっくり言うと ž 関連エンティティ ž VC発行者（Issuer）、利用者（Holder）、VC消費アプリ（Verifier） ž 単なるJSON/JSON-LDであるVCやVPへ、DIDに紐づく秘密鍵で署名をする ž OIDCと対比し、RP（Verifier）目線で言うとこんな感じ。 ž よくある質問 ž VCの発行元（VC内のIssuerとして指定されているDIDの持ち主）は誰か？をどうやって判 別・信頼するのか？ ž DNSにバインド。DID Document内のLinked Domainに記載のあるドメイン配下に/.well-known/did- configuration.jsonを配置。受け取ったら検証 → よく考えると結局疎結合になりきれない・・・ 取得元 Verify用の公開鍵 含めることのできる属性 何を信じるか Id_token IdP Jwks_uriから取得 IdPが発行したもの （Aggregatedだと元CPの署名検証は不 可） IdP VP Holder DID Documentから取得 複数のVCをVPに含めることで複数の発 行元から検証可能な状態で取得可能 DID Documentが格納され る分散台帳の系
- 27. 実は最も重要なこと）DIDとVCを切り離す ž VCはあくまでデジタル署名されたデータセット ž id_tokenとほぼ変わらない ž iss/subにDIDを用いる必要はない ž 実際、ワクチン接種証明はVerifiable Credentials ž スキーマ：FHIR ž Issuer：https://vc.vrs.digital.go.jp/issuer ž 署名：デジタル庁の自己証明書書 ž 参考） ž https://idmlab.eidentity.jp/2021/12/verifiable-credentials.html ž DIDと組み合わせることで得られるのは疎結合 ž 署名検証を���う際にIssuerの公開鍵を取得する方法の違い ž jwks_uriエンドポイントへのアクセスによる取得 → DID Documentから取得 ž DID Documentが分散台帳上にあることでIdP（Issuer）とRP（Verifier）の直接通信は不要となる
- 28. 分散型IDは自己主権型IDを実現するのか？ ž 「IDの所有」と呼ぶにはあまりにも限定的 ž 確かに事業者の都合で署名済みのVC＝デジタルIDが使えなくなるリスクは低減できる ž WalletにVCを入れればポータビリティっぽく見える ž 真の価値は「IDプロバイダへの依存度を下げる」ことではないか？ ž ユーザ目線では、「IdPが落ちていてもサービスが継続して利用できる」 ž 事業者目線では、「IdPの可用性要件を下げられる」「継続的なID管理が不要となる」 ž こう考えるとユースケースが見えてくる ž 情報管理はしたくないが、ID発行事業者として身元保証はしたい ž ID発行事業者に知られることなくサービスを利用したい ž IdPとサービスが連携できないスケールのサービス ž 例）大学における卒業生の管理、資格証明（資格試験、所属等）、スマートシティ、etc
- 29. ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限 → ID管理は利⽤者側へシフト ü 本⼈確認（eKYC等）によるIDリカバリが重要 ü 提供するIDサービス（認証等）も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス（認証等）を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携（密結合） なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 （ライセンス費⽤増） 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい （リスク増） ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要（疎結合） サービス 利⽤ 最低限のID管理で⼗分 （ライセンス最適化、 リスク低減） ID情報を個⼈に持たせ る＝ロストした場合の リカバリが必要 （本⼈確認） ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ
- 30. ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限 → ID管理は利⽤者側へシフト ü 本⼈確認（eKYC等）によるIDリカバリが重要 ü 提供するIDサービス（認証等）も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス（認証等）を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携（密結合） なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 （ライセンス費⽤増） 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい （リスク増） ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要（疎結合） サービス 利⽤ 最低限のID管理で⼗分 （ライセンス最適化、 リスク低減） ID情報を個⼈に持たせ る＝ロストした場合の リカバリが必要 （本⼈確認） ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ 卒業⽣、研究者のID管理シナリオ • 過去に在籍したことの証明 • 卒業・離籍後も⼤学に残した研究データへ継続的にアクセス許可 サプライチェーンのID管理シナリオ • 企業への所属証明、アクセス権限の証明 • OEM企業側でのID管理・パスワード管理の⼿間を⼤幅に削減 顧客、⾃治体における個⼈ID管理シナリオ • SNSを使った簡易ID登録と⾝元保証の両⽴、事業者への依存度低減 • 年齢等の⾝元確認（公的な⾝分証明の電⼦化） 従業員、学⽣のID管理シナリオ • ⼊社、⼊学時の⾝元確認（公的な⾝分証明の電⼦化） • パスワードレス、オンラインでのアカウント払い出し
- 31. Microsoft Entra
- 32. Microsoft Entra 3つのコンポーネントをまとめてリブランド ž Azure Active Directory ž Permissions Management（旧CloudKnox Permissions Management） ž Verified ID（旧Azure AD Verifiable Credentials） https://news.microsoft.com/ja-jp/2022/06/01/220601-secure-access-for-a-connected-worldmeet-microsoft-entra/
- 35. キーワードの整理 先に紹介したキーワード ž 分散型ID（Decentralized Identifiers） ž 検証可能な資格情報（Verifiable Credentials） Microsoft Entraにおけるキーワード ž 検証済みID（Verified ID） 読み解けること • 分散型ID（DID）とは切り離して考え、本質的な検証可能な資格情報（VC）にフォーカス • 資格情報（Credentials）だけではなくもっと幅広くIdentity（属性の集合）を扱う • 検証可能/検証済みの差についてはIdentity Proofing（KYC）とのセットで考えている
- 36. 想定されているシナリオ群 ž リモートオンボーディング ž アクセスのセキュリティ強化 ž アカウント回復 ž その他 https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
- 40. Entra Verified IDの歩き方 ž 組織IDの設定 ž 要するにIssuer設定 ž 資格情報 ž 要するにVerifiable Credentialsの設定 ž 発行と検証 ž Verifiable Credentialsの発行と検証 ž 発行済みVCの取り消し
- 41. 準備 ž 最低限必要なもの ž キーコンテナ（Key Vault） ž Azure Key VaultじゃなくてKey Vault ž ストレージアカウント（Blob） ž Verifiable Credentialsに表示するロゴファイル ž 定義体（Rules、Display）※Managedを使う場合は不要 ž Webサーバー ž Static Web AppでもOK（.well-knownというパスを作るのでStorageじゃダメ） ž DNSベースでIssuerを信頼するためのファイルを公開 ž did:web（既定）を使う場合はdid documentも公開 ž 合わせてデプロイ元となるGithubアカウントとレポジトリ ž API実行用のアプリ登録 ž Azure ADへのアプリ（client）登録とAPIアクセス許可 ž Preview時代に必要だったAzure AD Premium P2は不要になった
- 42. Key Vault設定 ž Entra Verified IDの設定を行 う管理ユーザへ[署名]権限の 付与（アクセスポリシー） ž Entra Verified IDの管理APIが Application Permissionでは なくDelegated Permissionで 動作するため管理ユーザに 権限付与が必要
- 44. Webサーバ設定 ž Entra Verified ID（Issuer）の所有権確認を行う ž /.well-known/did-configuration.jsonファイルの配置 ž DIFのWell Known DID Configuration仕様に従った実装 ž DIDがどの組織のものなのかを確認するため、DID Document内のLinked Domainとして設定 されたドメイン直下の.well-known/did-configuration.jsonにIssuerのDIDに関連するデータを 配置する ž VCを受け取ったエンティティ（HolderやVerifier）はVCのIssuerのDIDからDID Documentを取 得、Linked Domainに指定されたドメインからdid-configuration.jsonを取得、正しい発行者の DIDであることを検証する（DNSのガバナンスに依拠している） ž Webサーバはなんでも良いが、.well-knownというパスを作れる必要があるのでStorageだと ダメ（[.]始まりがNG） ž どっちにしろ後でIssuerのプログラムを配置することになるので、Web Appとかで良い
- 45. Entra Verified ID設定：組織IDの設定（Issuer設定） ž 組織名 ž Issuerの組織名 ž ドメイン ž IssuerのDIDにリンクされるドメイン名 ž DID Document内のLinked Domainの値 ž キーコンテナ ž Issuer DIDに紐づく鍵ペアの管理 ž 代替信頼システム ž DIDメソッド（did:webかdid:ion） ž 既定はdid:web
- 46. DIDメソッドの選択について ž did:web（既定） ž did:web:{リンクされたドメイン名}という形式。例）did:web:pharaoh.entraid.xyz ž DID Documentはhttps://{リンクされたドメイン名}/.well-known/did.jsonに配置される ž つまり、厳密には分散型IDではない ž did:ion ž did:ion:{内部識別子}という形式。例） did:ion:EiDBUQo0aGP1tSnp2….Wm13In19 ž Bitcoin上に構成されたSidetreeプロトコルであるION（Identity Overlay Network）を利用 ž DID/DPKIをサポートするため、Bitcoin上にLayer2を構成、多数のオペレーションを直接 Bitcoinネットワークへ流さないことで省エネ、省コストを実現 ž トランザクションがある程度溜まるまではIPFS上で管理（この間はlong-formの識別子を利用） ž 一定数溜まったらBitcoinへ書き込み（書き込み終わったらshort-formの識別子を利用）※現状のMicrosoftの実装で は書き込んでいない
- 47. ドメインの検証 ž did-configuration.jsonを 配置して所有権を検証 ž did:webの場合はdid.json （DID Documentそのも の）も配置する必要あり ž did:ionの場合はIONネッ トワーク上にDID Documentが浸透するま では検証できないのでし ばらく待ち（ion explorer で確認可） ION Explorer https://identity.foundation/ion/explorer
- 50. 資格情報の定義 ž 資格情報名 ž 表示の定義（Display） ž Authenticator上に表示される資格情報 ž ロゴ、色、��言 ž ルールの定義（Rules） ž 発行方法 ž 属性のマッピング
- 51. 表示の定義 ž locale：表示言語 ž card：資格情報（カード表記） ž backgroudColor：背景色（RGB） ž description：説明 ž issuedBy：発行者 ž textColor：テキスト色（RGB） ž title：タイトル ž logo：URL、description ž consent：同意に関する表記 ž claims：属性の表記 https://docs.microsoft.com/ja-jp/azure/active-directory/verifiable-credentials/credential-design
- 52. 表示の定義（例） { "locale": "en-US", "card": { "backgroundColor": "#000000", "description": "Entra Seminar Attendee's Proof", "issuedBy": "M365 Study Group", "textColor": "#ffffff", "title": "Entra Seminar", "logo": { "description": "Mokudai-san", "uri": "https://entrapharaohguitar.blob.core.windows.net/logo/ mokudai.jpeg" } }, "consent": { "instructions": "M365勉強会に参加した証です。", "title": "発行します。同意してね" }, "claims": [ { "claim": "vc.credentialSubject.firstName", "label": "Name", "type": "String" }, { "claim": "vc.credentialSubject.lastName", "label": "Surname", "type": "String" } ] }
- 53. ルールの定義 ž attestations：発行する資格情報のもととなる属性取得元 ž IdTokenAttestation： ž Authenticator内で外部IdP（OpenID Connect）で認証しid_tokenを取得 ž IdTokenHintAttestation： ž 事前にIssuer側で外部IdPで認証、発行リクエスト内に属性を指定（id_token_hint） ž verifiablePresentaionAttestation ž 別の資格情報から属性を取得 ž selfIssuedAttestation ž Authenticator内で属性値を自分で入力させ取得 ž mappings：発行元の属性と資格情報内の属性のマッピング ž validityInterval：資格情報の有効期間 ž vc/type：資格情報のタイプ https://docs.microsoft.com/ja-jp/azure/active-directory/verifiable-credentials/credential-design
- 54. ルールの定義（例） { "attestations": { "selfIssued": { "mapping": [ { "outputClaim": "firstName", "required": true, "inputClaim": "firstName", "indexed": false }, { "outputClaim": "lasttName", "required": true, "inputClaim": "lastName", "indexed": true } ], "required": false } }, "validityInterval": 2592001, "vc": { "type": [ "VerifiedCredentialExpert" ] } }
- 56. 資格情報の発行 ž 2通りの発行方法 ž Issuance APIを実行する ž Azure ADに登録したアプリケーションの権限で実行する（client_credentialsで取得したaccess_tokenを使用） ž Issuance APIを使う発行用のWebアプリケーションの開発が必要 ž 一般コンシューマ向けの資格情報発行シナリオ ž OpenID for Verifiable Credential Issuanceの仕様に則ったやりとり ž https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html ž 組織に登録されたAuthenticatorへプッシュ通知を送る ž Azure ADのグループ単位でプッシュ ž 従業員向けの資格情報（社員証、学生証など）発行シナリオ ž 現状はIssuance APIを利用する方法のみ利用可能
- 57. 資格情報の発行 ž 呼び出すAPIエンドポイントとRequest Bodyのテンプレート ž 値を置き換えて利用 ž Callback ž Authority ž Registration ž Issuance ž 通常はアプリ内でAPI を呼び出すがPostmanで テストする
- 63. 資格情報の検証 ž Presentation APIを実行する ž 基本的な考え方はIssuance APIと一緒 ž エンドポイントも同じ ž Request BodyのIssuance部分をPresentationに変えるだけ "presentation": { "includeReceipt": true, "requestedCredentials": [ { "type": "VerifiedCredentialExpert", "purpose": "the purpose why the verifier asks for a VC", "acceptedIssuers": [ "did:ion:pQy1oU0ZVblRfkhqZ2Y5bjFOamJUQnZ1Wm13In19" ] }] }
- 64. 資格情報の検証 ž callbackに指定したURLへ提示されたVCの情報が送られてくる ž OpenID for Verifiable Presentationに則ったやりとり ž https://openid.net/specs/openid-4-verifiable-presentations-1_0.html ž Body ž id_token ž Subject ž Audience ž VP（Verifiable Presentation）に関するメタデータ ž vp_token ž 提示されたVCを含むトークン
- 66. 発行済みVCの取り消し ž VCのライフサイクル ž 有効期限：VC発行時に設定（Verify時に期限切れとわかる） ž 明示的な取り消し：管理ポータルから取り消し（現状APIは未提供） ž 明示的な取り消し ž Index属性をベースに取り消し（ルール定義でIndexed: trueにした属性）
- 67. まとめ＋α
- 68. 再掲）ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限 → ID管理は利⽤者側へシフト ü 本⼈確認（eKYC等）によるIDリカバリが重要 ü 提供するIDサービス（認証等）も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス（認証等）を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携（密結合） なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 （ライセンス費⽤増） 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい （リスク増） ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要（疎結合） サービス 利⽤ 最低限のID管理で⼗分 （ライセンス最適化、 リスク低減） ID情報を個⼈に持たせ る＝ロストした場合の リカバリが必要 （本⼈確認） ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ
- 69. 再掲）ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限 → ID管理は利⽤者側へシフト ü 本⼈確認（eKYC等）によるIDリカバリが重要 ü 提供するIDサービス（認証等）も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス（認証等）を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携（密結合） なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 （ライセンス費⽤増） 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい （リスク増） ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要（疎結合） サービス 利⽤ 最低限のID管理で⼗分 （ライセンス最適化、 リスク低減） ID情報を個⼈に持たせ る＝ロストした場合の リカバリが必要 （本⼈確認） ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ 卒業⽣、研究者のID管理シナリオ • 過去に在籍したことの証明 • 卒業・離籍後も⼤学に残した研究データへ継続的にアクセス許可 サプライチェーンのID管理シナリオ • 企業への所属証明、アクセス権限の証明 • OEM企業側でのID管理・パスワード管理の⼿間を⼤幅に削減 顧客、⾃治体における個⼈ID管理シナリオ • SNSを使った簡易ID登録と⾝元保証の両⽴、事業者への依存度低減 • 年齢等の⾝元確認（公的な⾝分証明の電⼦化） 従業員、学⽣のID管理シナリオ • ⼊社、⼊学時の⾝元確認（公的な⾝分証明の電⼦化） • パスワードレス、オンラインでのアカウント払い出し
- 70. 再掲）想定されているシナリオ群 ž リモートオンボーディング ž アクセスのセキュリティ強化 ž アカウント回復 ž その他 https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
- 71. DID/VC開発者向けコミュニティを立ち上げます Japan DID Developer Community ž DID/VCに興味がある人が集まる場 ž Discordチャネル開設しました ž https://discord.gg/nn53BRRz ž これからのコミュニティなので一緒に盛り 上げていってもらいたいです！