Verifiable Credentials と Decentralized Identifiers についての”超”概要

自己紹介 うえにし (Xアカウント → @uk092908) ・2021年5月からエンジニア ・主に扱っている技術 (TypeScript, React, Next.js) ・最近転職して、5月から受託開発企業でフロントエンド (フル スタック？) エンジニア ・最近ムエタイジムに通い始めました ・元バンドマン (ギター) ・お酒好き

本日のネタ 以前の現場で関わったデジタルアイデンティティ関連の技術について、概要を解 説してみる (“超” 概要です) ・自己主権型アイデンティティ (Self Sovereign Identity - SSI) SSI を実現するための技術的要素 ・分散型識別子 (Decentralized Identifiers - DID) ・検証可能な資格情報 (Verifiable Credentials - VC)

デジタルアイデンティティとは？ 人間などの主体（entity/subject）をコンピュータで処理するためのアイデンティティ情報であり、そ れぞれの属性情報から成る。 ISO/IEC 24760-1は、アイデンティティを「実体に関する属性情報の集合（ set of attributes related to an entity）」と定義している 参照 “デジタルアイデンティティ” https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%82%A2%E3%82%A4%E3%83 %87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%86%E3%82%A3

デジタルアイデンティティとは？ 人、組織、デバイス、サービスなど、 属性を管理 する単位のことをエンティティ（主体）といい IPA2013(p5)、システムに登録されたエンティティに 関する属性情報の集合を アイデンティティ情報 というIPA2013(p5)。アイデンティティを電子的に表 現したものをデジタルアイデンティティ という 参照 “デジタルアイデンティティ” https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E 3%82%BF%E3%83%AB%E3%82%A2%E3%82%A4%E3%8 3%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%86 %E3%82%A3

“Identity” と “Identifier” の違いに注意する 第1回 「アイデンティティ管理」の周辺事情を整理しよう https://atmarkit.itmedia.co.jp/fsecurity/rensai/kantara01/kantara01.html Identity (同一性) と Identifier (識別子) が同じように “ID” と表現されていたりすることがあるのでややこしい

自己主権型アイデンティティ (SSI) とは？ ・「個人は、管理主体が介在することなく、自身のアイデンティティを 所有しコントロールできるべき である」と考えるデジタル・ムーブメントを表す言葉である。 ・2016年にSSL/TLSの専門家 クリストファー・アレン氏が「 SSIの10の原則」を提唱し広まった ・昨今では管理主体 (googleのようなIdP) がID・パスワードなどを管理している 　→ 管理権限が事業者側にある限り、個人情報の管理・利用はブラックボックス 　→ これを個人の意志で自由に制御できることを目指している

https://sovrin.org/wp-content/uploads/Principles-of-SSI-V1.01-Japanese-v01.pdf

自己主権型アイデンティティ (SSI) とは？ 出典 https://blog.goodaudience.com/how-blockchain-could-become-the-onramp-towards-self-sovereign-identity-dd234a0ea2a3

自己主権型アイデンティティ (SSI) とは？ IdPのような特定の管理主体がデジタルIDを集中管理していると何がまずいのか ・事業者が消滅したりすると、自分を証明する手段がなくなる 　→ 例えばパスポート (管理主体 - 国) 　　→ 国がなくなってしまうと、アイデンティティを証明できなくなってしまう

分散型識別子 (DID - Decentralized Identifier) とは？ ・特定の事業者に依存しない識別子 (Identifier) DIDは3つの部分からなる単純なテキスト文字列である。 1) DID URIスキーム識別子、2) DIDメソッドの識別子、3) DIDメソッド固有の識別子。 出典 https://www.w3.org/TR/did-core/

分散型識別子 (DID - Decentralized Identifier) とは？ DIDとDID Document 　DID Documentとは、DIDで示される主体（エンティティ / サブジェクト) を表現するのに必要なデータ 　公開鍵や特定のブロックチェーン情報が記載される 出典 https://www.w3.org/TR/did-core/

DID Documentのサンプル { "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", "authentication": [{ // used to authenticate as did:...fghi "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "service": [{ // used to retrieve Verifiable Credentials associated with the DID "id":"did:example:123456789abcdefghi#vcs", "type": "VerifiableCredentialService", "serviceEndpoint": "https://example.com/vc/" }] }

分散型識別子 (DID - Decentralized Identifier) とは？ DIDメソッドについて did:example:123456abcderf…. の、example にあたる部分 did:web, did:ion, did:ethr などいろいろと乱立しており 2024年1月時点で186個もメソッドが登録されているそう (https://idmlab.eidentity.jp/2024/01/didwebdidwebs.html)。後に続く識別子はメソッドに依存しているため、 DIDメソッドを超えて識別子 を引っ越しすることはできない。 「分散型」と言いつつも、メソッド did:web の場合は did:web:xxx.com のような形となり (xxx.comはドメイン名) 厳密には分散型ではな い。この場合はDID Documentは “https://xxx.com/.well-known/did.json” に配置される。

分散型識別子 (DID - Decentralized Identifier) とは？ DIDまとめ ものすごーいざっくりいうと、 ・DIDに紐づく公開鍵情報などの情報を含む DID Documentを “分散台帳等” で保持し、アクセス可能にする仕組み ・DID ≒ 特定企業やサービスの運営体に依存しない ID (識別子) の発行管理方法 ・特定企業 〜 サービスを超えてID (識別子) を活用することが可能 ・ID管理はDIDメソッドに依存する。異なる DIDメソッドの行き来はできない ・DIDに紐づく秘密鍵で署名したデータを DID Document上の公開鍵を用いて検証することで、 DIDの「持ち主」が発行したデータであることを検証できる （後述のVerifiable Credentialはこの仕組みを利用 )

検証可能な資格情報 (VC) とは？ ・Verifiable (検証可能) な Credential (資格情報) ・W3C (World Wide Web Consortium) で提唱されているデジタル資格情報の標準 仕様 ・実態は電子署名が施されたJSON形式のドキュメント ・デジタル上で証明書をユーザーが保持し、個人の情報を提供することができるよう にするためのもの

検証可能な資格情報 (VC) とは？ 引用 https://lastrust.io/2020/05/25/whatisverifiable-credentials/

検証可能な資格情報 (VC) とは？ 引用 https://www.w3.org/TR/vc-data-model-2.0 Verifiable Credentialの構成 Proofには発行者の署名が入る。Verifiable Presentationは保有者が検証者に提出する際のフォーマットで、複数の Verifiable Credentialを格納できる (Proofには保有者の署名が入る)

検証可能な資格情報 (VC) とは？ 登場人物 発行者 (Issuer) 行政や企業、教育機関など 保有者 (Holder) 資格情報を保持する人 検証者 (Verifier) 資格情報が正しいかを検証す るところ (アプリケーションなど)

検証可能な資格情報 (VC) とは？ 検証の流れ 発行者 (Issuer) 保有者 (Holder) 検証者 (Verifier) Verifiable Data Registry (分散台帳など)

検証可能な資格情報 (VC) とは？ 検証の流れ 発行者 (Issuer) 保有者 (Holder) 検証者 (Verifier) Verifiable Data Registry (分散台帳など) Issuerの秘密鍵で 署名されたVCが発 行される Issuerの秘密鍵に 紐づいたDID/公開 鍵が登録される Holderの秘密鍵に 紐づいたDID/公開 鍵が登録される 要求されている Credentialを提出 Credentialに含まれ るIssuer & Holderの 情報 (DID) から、公 開鍵情報を取得 取得した公開鍵で 検証を行う Holderが保有す るWallet等にVC を保存

検証可能な資格情報 (VC) とは？ VCとDIDを使うことで何がいいのか ・検証を行う際に発行者への問い合わせが不要 　→ 発行母体がなくなったとしても、分散台帳上に公開鍵暗号情報が存在する限 り、検証を行うことができる

検証可能な資格情報 (VC) とは？ 実際のユースケース ・デジタル庁 ・ワクチン証明書 ( DIDを用いていないVerifiable Credential) ・good digital awardの賞状 ・慶応義塾大学 ・2020年より在学証明書や卒業見込み証明書などをデジタル化する実証　　　 実験を開始

VC × DID 運用の課題 ・秘密鍵管理のハードル → ユーザーが保有する = どこかで秘密鍵の管理が必要 ・Cold Wallet や Hot Walletなど…どう管理するか ・DIDメソッドの選択 → 大量のDIDメソッドが乱立しているため、用途に合わせた選定の難しさ

デジタルアイデンティティについての世界的な動き 引用 https://www.i-ise.com/jp/information/report/2023/231117.pdf

まとめのようなもの ・技術基盤としては公開鍵暗号方式での検証であり、DID / VC そのものには技術的 な新しいものはない ・在り方、仕組みとして新しいものであり、今後いろいろと拡張や整備されていきそう ・Verifiable Credentialsを実際に発行してみたい！ という方は “Microsoft Entra Verified ID” というサービスから発行することができます ・デジタルアイデンティティの証明について「どこに責任を置くか」という観点で見ると 答えはなく、面白いところでもある

ありがとうございました！