こんにちは。GMOグローバルサイン・ホールディングスCTO室で分散型アイデンティティの研究をしている開発者の神沼@t_kanumaです。
この記事では題目の通り、昨今のこの領域の潮流と、その中でのKERI Suite(KERI, OOBI, ACDC, IPEX, CESR)の立ち位置を考察したいと思います。あくまで私の視点・解釈による見方ですので一つの考察として気軽にお楽しみください。
1. 潮流
1-(1). パブリックセクターによる主導
昨今はパブリックセクターが主導し、プライベートセクターと協働する形で普及に向けた段階に入っていると思います。例えばEU Commisionが主導するEUDIW、アメリカの各州およびAAMVA(American Association of Motor Vehicle Administrators)が主導するISO mDL形式のデジタル運転免許証、そして日本でもデジタル庁がマイナンバーカード券面事項のISO mdoc化に向けて動いていると認識しています。
この形の理由についてですが、この分野の本質的な部分にフォーカスするとそれが見えてくると思います。それは「便利になる」、「意味がある」の二軸で見た時に、この分野は(0か100ではなくグラデーションはあると思いますが)前者ではなく後者であることです。人類は古来より「便利になる」方向で文明・ビジネスを発展させてきたと思いますが、この分野が目に見えて劇的に何かが楽になったり、UXが変わるようなコトだとは思えません。目指しているものは、個人のプライバシーに配慮したデジタル社会のより良いあり方の実現だと考えます。
そしてこのような「意味がある」コトは、一部の愛好者・信仰者・マニアを除き、ボトムアップで大衆に普及させることは中々難しいのではないでしょうか。そのように考えると国造りをするパブリックセクターが制度策定などでトップダウンで関わっていくことは自然な流れに感じます。
そういった中で思想・技術的な流派は、おおまかにメインストリームとオルタナティブに二分できると考えます。
1-(2). 思想・技術的流派〜Administrativeモデルに対する肯定・否定〜
標準化団体名(標準)の形で記述しています。
- メインストリームグループ(主流派)
- OIDF(OID4VC)
- ISO(mDL/mdoc, 18013/23220 series)
- オルタナティブグループ
- DIF(DIDComm, Decentralized Web Node), Hyperledger(Aries RFC)
- AriesはDIDCommを基盤の1つにしていて、元々の発祥元でもあり、DIFとの繋がり・親和性を見て取れるためシンプルにするために同一レベルで記載しました。
- ToIP(KERI Suite)
- DIF(DIDComm, Decentralized Web Node), Hyperledger(Aries RFC)
The Architecture of Identity Systemsより引用
両者の根本的な部分での違いは、Phil Windley氏による記事「The Architecture of Identity Systems」にて述べられている、コントローラー – 識別子 – 公開鍵ペアの三角形において、識別子と公開鍵ペアの間の永続的な(=ローテート可能な)バインディングに対する考え方および方式にあると考えています。
Admnistrativeモデル
The Architecture of Identity Systemsより引用
Administrativeモデルは、すでにWeb上で広く普及しているアプローチです。代表的なケースとしては、識別子がWebドメイン、公開鍵がX.509サーバ証明書である例が挙げられます。この場合、CA(認証局)がAdministratorの役割を担い、Webサーバの運用者がControllerとなります。
識別子と公開鍵のバインディングは、CAによるVetting(審査)によって達成されます。また、Controllerと公開鍵のバインディングは、TLSプロトコル内での署名もしくは鍵交換によって実現されると考えます。
主流派
主流派はAdministrativeモデルを肯定していると捉えるとわかりやすいと思います。例えばOID4VCでは、既存のWeb技術に沿ったクライアントサーバー型のHTTPS通信を前提としています。
また、OID4VCは識別子スキーム・VCフォーマットフリーに作られており、そのため、柔軟な識別子の管理が可能です。特に、親和性の高い現在主流となりつつあるIETF SD-JWT VCとの組み合わせにおいては、Issuerが用いるSD-JWT VC署名鍵の識別子スキームの手段の一つとして、WebベースなJWT VC Issuer Metadataを選択することができます。これは、識別子と公開鍵のバインディングにおいて、CAやWebサーバーを利用するという点で、Administrativeモデル的と言えるかと思います。
さらに、アメリカ各州のモバイル運転免許証(mDL)においては、AAMVAがIssuerの公開鍵をX.509証明書としてTrusted Listに登録し、Web上で公開しています。これは、識別子と公開鍵のバインディングを通信においてはCAが、保管についてはAAMVAのWebサーバーで担うということで、同様にAdministrativeモデルの実例と言えるかと思います。
オルタナティブグループ
オルタナティブグループには以下の特徴があります。まず、標準にもよりますが、この分野では先発組です。
このグループは、既存のインターネット、Webの在り方に批判的です。Administrativeモデルを否定し、よりアルゴリズムやプロトコルを重視したアプローチを提唱しています。その一環として、ブロックチェーンを利用したAlgorithmicモデルを採用し、さらに進化した形として、KERI ProtocolのAutonomicモデルへと繋がっています。(本稿のメインテーマであるため、詳細は後述します。)
また、通信においてもクライアントサーバー型ではなく、通信者同士が対称になるP2P型を採用し、通信者の公開鍵をOut-Of-Bandの何かしらの信頼できる手法で交換することで、TLS/CAに依存しない形で、言い換えればHTTPSを要さずHTTPであってもセキュアな通信を実現します。(DIDCommやKERI Message)
現状とのギャップの大きさの違いと受け入れられやすさ
まとめとして、なぜ後発の主流派が主流になりえたのか。その仮説を立てると、主流派は実用性に沿って発展してきた既存のWeb技術やPKI、JWTなど周辺技術の延長線上にあり、現状とのギャップが小さく、受け入れられやすかったからだと考えられます。たとえば、主流派としてISO mDL/mdocがありますが、これらは近接通信技術においても、すでに普及しているBLEやNFCを利用しており、既存技術のコンセプトの延長線上にあることが特徴です。一方で、オルタナティブグループはそもそもの「あるべき姿」からスタートし、高い理想論を掲げているため、現状のWebとのギャップが大きいといえます。そのアプローチには、識別子と公開鍵間の関係において、CAなどのAdmin的存在を排除し、そのバインディングをプロトコルレベルで定義することを目指している特徴があります。(以下、そのイメージ図です。)
これは、VCのフォーマット種別に関しても同様の傾向が見られます。現在主流となりつつあるIETFのSD-JWT VCは、仕組みの説明が比較的容易である一方で、オルタナティブグループ発祥の先発技術であるHyperledger AnonCredsは、Private Holder BindingにおけるLink Secretや、PredicatesにおけるZKP(ゼロ知識証明)などの仕組みにおいて高度な数学的知識を要するため、一般の開発者が全ての説明責任を負うには敷居が高いと感じます。
ここまでを一言でまとめると、現実的でコンサバティブな主流派、理想論的でリベラルなオルタナティブ派と言えるかもしれません。
1-(3). Trust/Governance FrameworkとTrusted List
重要なポイントとして、コントローラー – 識別子 – 公開鍵ペアの三角形におけるバインディングの確立と、コントローラー自体が信頼できるエンティティであるかどうかは別の問題であると理解しています。例えば、Webページへのアクセスでは、PKIとTLSの仕組みにより三角形のバインドが技術的に確立されますが、これだけではそのドメインのコントローラーが悪意を持っていないか、期待通りの動作をするかまでは保証されません。もしこれが保証されていれば、フィッシング詐欺は消滅しているはずです。これは、ブロックチェーンやKEL(Key Event Log/後述します)に公開鍵が格納されていても、DIDやAID(Autonomous Identifier/後述します)のコントローラーが信頼できるかどうか、悪意のある行動を取らないか、期待する行動をとるかどうかとは直接関係がないことを示しています。リベラル的なオルタナティブグループであっても、この点については変わらないと考えます。こうした課題に対処するためには、一般的に「Trust Framework」や「Governance Framework」と呼ばれる枠組みが登場します。その中で、信頼を確立する具体的な仕組みはいくつかあると思いますが、ここではEUDIWやアメリカ各州のmDLで採用されているTrusted Listについて述べます。
EUDIW ARF(Architecture and Reference Framework) 1.4
Trusted Listは、そのエコシステム内で信頼される中央機関が、IssuerやVerifier、Wallet Providerなどの各エンティティを審査・承認し、それらの公開鍵をリスト化してWeb上で公開するものだと理解しています。
EUDIW ARF1.4 Annex 2(High-Level Requirements)を読んだ結果として、実際の物理的な配置はわからないですが、論理的にはTrusted Listを以下の3つに分けて整理できると思いました。
- Verifier(RP)がVCの検証のために参照するList。Issuer(Attestation Provider)の公開鍵(Trust Anchor)が登録されている。
- IssuerおよびVerifierがOID4VCI/VPなどの中で、後述するWallet Trust Evidence(WTE)を通したWallet Instance(App)の認証のために参照するList。Wallet Providerの公開鍵が登録されている。
- Wallet InstanceがOID4VCI/VPなどの中でIssuerおよびVerifierを認証するために参照するList。IssuerおよびVerifierに対しAccess Certificateを発行したCAの公開鍵が登録されている。
- Access Certificateの証明書チェーンに対する標準の指定はない。X.509-based CA、OpenID Federation、またはその他でも可。
アメリカ各州のモバイル運転免許証(mDL)において、標準化と相互運用性、セキュリティの確保を役割に持つAAMVAのMobile Driver’s License Implementation Guidelinesを読むと、公開鍵のフォーマットはX.509証明書に固定されていますが、上記から察するにEUDIW ARFでは各メンバーステート(国)ごとに選択の余地があるのかもしれません。ここら辺のARFの具体化、物理化の詳細について今後、理解を深めていきたいです。
1-(4). Holder BindingとWallet Attestation
主流派において今一番ホットなトピックは、Holder BindingにおけるWallet Attestationではないでしょうか。Holder BindingとはHolderとCredentialの間の紐付けで、Proof of Legitimate Possesionとも表現できますが、(Holder = VC Subjectの前提で)HolderがそのVerifiable CredentialsのSubjectに該当すること、つまり正当な発行先、保持者であることをVerifierに証明することです。
EUDIW ARF v1.4ベースでの話になりますが、このように考えるとわかりやすいと思う私の理解を図に起こしました。
左側の赤い線をバインドするために、時計回りに順々に紐付けを行っていく見方です。
ここで今回深掘りしたいのがNo.2のWTE(Wallet Trust Evidece)の発行と提示です。
上図のように、Wallet Instance(App)のライフサイクルの初期段階において、それがアクティベートされた際に、Wallet ProviderがTrusted Listに登録されている公開鍵に対応した秘密鍵でWallet Instanceに対しWTEを発行(署名)します。このWTEの中で署名対象になっているペイロードはHolderのWTE用公開鍵であり、その秘密鍵はWSCD(TEE, Secure Enclave, eSIMなど)にて保管されています。HolderはVC発行の際に、このWTEに対し、WTE用秘密鍵で署名してIssuerに提示します(VCに対するVPの様に)。そしてIssuerはHolderの署名と、Wallet Providerの署名を検証します。Wallet Providerの署名検証の際には、Trusted Listから信頼できる公開鍵を取得して行う、というのが基本的な仕組みです。
ここでポイントとなるのが、HolderのWTE用公開鍵ペアは、VCのSubjectにあたる公開鍵ペアとは異なるという点です。なぜかというとOID4VCIのBulk-Issueの存在目的のように、Subjectにあたる鍵は、その識別子が名寄せのポイントにならないようVCごとに変えるのがプライバシー上のプラクティスとされており、ライフサイクル初期に一度だけ発行されるWTEの鍵には設定できません。この状態では、IssuerとしてはWTE Payloadの鍵は信頼できるものの、VC Subjectの鍵は信頼できません。EUDIW ARF1.4 Annex 2(High-Level Requirements)には、このSubjectの鍵とWTEの鍵の紐づけの仕組みの部分については近々Whitepaperを出すと書かれており、追っていきたいと思っています。
また別のポイントとして、Wallet InstanceのActivationにおいて、Wallet InstanceとWallet Providerの相互の認証の具体的な手法というのは、EUDIW ARFの範囲外になっていることをあげます。
このWTEの仕組みは、IETFにおいてOAuth 2.0 Attestation-Based Client Authenticationとして標準の策定が進められており、これがOIDFのOID4VC HAIPやISO 23220-3にて参照されている模様ですが、やはりここでもその認証の手法は範囲外です。WalletにAPI Keyを埋め込むとリバースエンジニアリングされる危険がありますし、ここをどう実装していくのか今後、探っていきたいと考えています。(詳しい方いましたらぜひご教示いただきたく、ご連絡お待ちしております。)
またアメリカ各州のモバイル運転免許証(mDL)においても前述のAAMVA Guidlinesにおいて以下の記述があります。
It is up to Issuing Authorities to ensure that all mDL data stored on the mDL holder’s device is adequately protected. As standards in this respect are still under development, each Issuing Authority should
take great care to ensure that the design of its solution supports this requirement. At minimum, Issuing Authorities must adhere to the following:
これはWallet(Device) Attestationのことを指していると考えており、この分野が普及していく上での重要な技術的要素(ラストピース)になっていると感じます。
1-(5). W3C DIDsとブロックチェーンの存在感の低下
私が今年聴講したヨーロッパ最大のカンファレンスであるEuropean Identity Conferenceでは、(後述しますが「HolderへのCredentialの集中化」という文脈での)分散型アイデンティティが一番大きいトピックでした。その中で、「Where did blockchain go?」と語る人もいたりと、W3C DIDsとブロックチェーンが登場するセッションは私が確認する限りゼロではないにしろ、かなり少数であったと記憶しています。またもう1つのトピックの柱は生成AI時代におけるアイデンティティについてでした。
前述した4つのグループの中で唯一W3C DIDsを重要視し、DIDCommやDecentralized Web Nodeなどそれを前提にしている仕様を持つのはDIFです。DIFからは、W3C DIDsをなんとか主流派に接続しようとする動きが見て取れます。例えば、OpenIDIDCommという取り組みではOID4VCIを壊すことなく、そこにDIDCommを組み込むことでセッションを永続化するモノです。他にはDIF幹部の方々がGitHub上でEUDIW ARFにW3C DIDsを取り入れる要求をIssueとして出す動きがありました。しかしこれらが上手く発展していっている感じは見受けられません。
ここでW3C DIDsの存在感が上昇しない理由の仮説を立ててみます。
W3C DIDsの一番の特徴は、それが識別子体系のメタシステムであり、識別子と公開鍵の表現を標準化し、公開鍵取得方式の違いをResolver実装にて吸収することによる、エコシステム間における相互運用性を高められることだと考えています。
もともと2010年代後半の世間的、ガートナーのハイプライフサイクル的にもブロックチェーンに対する期待や熱量が高かったころに登場しています。最初の動機はわかりませんが、公開鍵を管理することになるブロックチェーンがたくさんあることも1つ要因になっているのかもしれません。これは時系列的にも既存Webの公開鍵の識別子体系(Web-based、生JWK、PKI/X.509証明書)に対するDIDメソッド(それぞれdid:web、did:jwk、did:x509)が登場するのは、後になってからだったということからも推察できます。
では、その特徴が最も活かされるケースは何なのかを考えてみます。用いるアナロジーとしては異なる鉄道会社の路線の直通運転・相互接続です。あくまで素人としての推測ですが、直通運転を決める際にはお互いの会社のガバナンスとそれに則る運用を信用することが前提になると思います。これと同様に、異なるガバナンスフレームワークを持つエコシステムが互いに信用し合った時に、W3C DIDsをあらかじめ使っていれば、公開鍵取得方式の違いをResolver実装に吸収でき、インターフェイス(識別子と公開鍵表現フォーマット)を変更せずにスムーズに接続できる余地が生まれるわけです。(規格化された車体や線路を使っているイメージです。)
つまりは、その際に初めて価値が生まれるわけで、そのような状況になるか、もしくは全員がせーの！でW3C DIDsに乗り移らない限り、上記の既存方式が移行する動機は生まれないのではないでしょうか。そして残念ながら、現在は未だそういった異なるガバナンスフレームワークを持つ異なるエコシステムが相互接続する状況に至っていないと考えます。(これは通信のメタプロトコルであるDIDCommについても同様に言えるのかもしれません。)
ここから少し視点を変えて見ます。
分散型アイデンティティの先発者として登場したHyperledger Indy/Aries(DIDComm)ですが、それが主張する「分散型」に対して2つの意味があったと考えています。(ここが一緒くたにされてしまい、切り分けられて上手く伝わらなかったことが、テック寄りではない人にとって特に、そしてこと日本において特に、この分野がweb3/Web3.0の一部の取り組みであると誤解されてしまう要因になっていたのかもしれません。もし主流派が先発組として登場し、最初から主導権を握っていたら、DecentralizedやSelf-Sovereignといった所謂「主語がでかい」呼称になっていなかったのかもしれませんね。)
- HolderがモバイルデバイスにCredentialsを保管すること。
- フィジカルモデルのデジタル化(いつどこで誰にどの目的でCredentialを提示するかをHolder次第にする)
- アイデンティティの個人への集中化(分散と集中は表裏一体です)
- Phone Home問題の解決
- (主流派のスコープはこちらだけ)
- 前述の識別子と公開鍵ペアのバインディングにおいて、ブロックチェーンを使うことでAdministrativeモデルを脱しAlgorithmicモデルへ移行すること。
- 多数の運用参加者に状態管理をアルゴリズムに依存する形で分権する。
- 人による運用が入ったAdminitrativeモデルに対し、アルゴリズムが支配するイメージ。
Algorithmicモデル
The Architecture of Identity Systemsより引用
このうち、No.2の存在感が低下しているのが実情ではないでしょうか。それには2つの理由があると考えています。まず1つ目は世間一般のブロックチェーンに対する一時の熱狂的な盛り上がりが落ち着いたことです。2017年開始以降のdid:indy(sovrin)に作られたDID数を見ていくと、ピークは2021年のだいたい1400個で、それ以降は毎年150~350個程度で推移しています。またdid:indyとセットで語られることが多かったMicrosoft社発のdid:ionにおいてもWeb5プロジェクトがデフォルトメソッドをionからブロックチェーンレスなdid:dhtに切り替えるなど、広がりを見せるニュースは私の知る限りでは聞きません。
DIF Decentralized Web Nodeを実装し、W3C DIDsベースでPersonal Data Storeを実現するWeb5プロジェクトに関しても、web3に対するカウンターパートとして登場した経緯があると理解していますが、やはり対抗相手のweb3ブームの落ち着きからか、2024年に入ってからは話題に上ることが少なくなっているように思えます。
2つ目の理由として、識別子と公開鍵ペアの永続的なバインディングにおいて、Sam Smith教授が2019年にKERIの論文を発表したことで、前述のAlgorithmicモデルがAutonomic(自律型)モデルへと進化したことがあげられます。詳細は前述のPhil Windley氏による記事およびNuttawut Kongsuwan氏の記事「The Hitchhiker’s Guide to KERI. Part 1: Why should you adopt KERI?」をご参照いただくとして、ここでは端的に述べます。デジタルアイデンティティにはそもそもブロックチェーンの動機、革新の根源であった通貨における二重支払い問題は存在しないため、ネットワーク全体で状態を同期するための合意の仕組みの必要が無いというのがポイントです。イメージとしてですが、自己に関するアイデンティティ情報に署名し、他者に提示・主張をしても、それで自分の何かが減ったり、誰かの状態が直接変わったりすることはないですよね。KERIは、ブロックチェーンなど他のモデルでは存在した3rd Partyを完全に排除する形で永続的なバインディングを実現します。この性質がまさに「Autonomous = 自律性、自治性」の由来だと考えます。ここからKERIの基本的な仕組みとそのユースケースについて述べます。
Autonomicモデル
The Architecture of Identity Systemsより引用
1-(6). 補足: W3C VCDMについて
KERIに向かう前に少し補足ですが、W3C DIDsだけでなく、それと同時期に登場しセットで語られることが多かったW3C Verifiable Credentials Data Modelも、VCフォーマットの戦いにおいてIETF SD-JWT VCに押され、多くの人にとってファーストチョイスではなくなっているのではないでしょうか。これは上図でも触れていますが、バージョン2.0でJSON-LDに表現が絞られたことが大きな要因だと思います。やはり、As-IsとTo-Beを考えると、Semantic Webに連なるLinked DataとJWTでは現状に対するギャップの大きさに差があり、受け入れやすさに違いがあるのは明白です。このように、後発組が先発組を追い抜く現象は、IT業界のサービスやプロダクトでも散見される事象であり、その縮図を見ているようで興味深いです。
2. KERI Protocol
2-(1). AIDとKEL
ここからKERIの仕組みの概略を下図を元に説明します。
KERIではKEL(Key Event Log)が中心的な役割を持ちます。KELを一言で表せば、「一連のキーイベントを時系列順に記録したログ」だと考えます。初期の公開鍵ペアの生成イベントをKey Inception Eventといい、ここからAID(Autonomous Identifier)を一方向関数により導出します。ここでまずローテーション前の鍵とAIDが3rd Party抜きで暗号技術的にバインドされました。この状態の識別子をKERIではSCID(Self-Certified Identifier)と呼びます。SCIDの性質を持つと考えるDIDメソッドはいくつかあり、例えばdid:keyやdid:indy、did:ionが該当します。AIDとの違いは、did:keyはローテーションしないメソッドであり、そしてdid:indy,ionでは初期の鍵ペア以降の、ローテートされた鍵ペアとDIDのバインドをブロックチェーンが担います。
KELのバインディングのポイントは2つあると考えます。
まず1つ目ですが、KELでは、AIDのコントローラーは現在のイベントに対し、ローテート後、すなわち次の鍵ペアを予め作っておき、その公開鍵のコミットメント(ダイジェスト)を現在のイベントに入れ込みます。これにより、次の鍵ペアを作った本人のみ、次のローテーションイベントを作る正当性を持つことができます。(本人以外が作っても後で検知可能。)
そして2つ目ですが、現在のイベントは前のイベントのハッシュ値を持ち、ログ全体がハッシュチェーンの構造を持ちます。これにより最新のアクティブな公開鍵イベントから、古い公開鍵イベントを辿ることで、最終的にAIDまで3rd Party抜きにたどり着けるわけです。(より詳しい内容はKongsuwan氏の記事「The Hitchhiker’s Guide to KERI. Part 2: What exactly is KERI?」をご参照ください。)
そして、このKERI Suiteの存在感がじわじわと高まっていると感じます。今年の春のIIW(Internet Identity Workshop)では、KERI関係で18個のセッションが開催された模様です。そして今後国際的な組織向けのデジタルアイデンティティの中心になる可能性がある以下のユースケースに採用されています。
2-(2). KERIとGLEIF vLEI
ここまで書いてきた内容以上のKERI Suiteの詳細については、各種標準の参照、または既に登場しましたがFinema社のNuttawut Kongsuwan氏が執筆した記事群を参照されることをお勧めします。これらの記事は非常にわかりやすく構成・執筆されており、とっかかりとして最適です。
私の知る限り、KERI Suiteを採用している現在唯一のユースケースは、GLEIF(Global Legal Entity Identifier Foundation) がVerifiable Credentials(ACDC)として発行するvLEI Credentialです。GLEIFはG20と金融安定理事会(FSB)の要請で設立された独立した国際的な非営利団体です。厳密にはパブリックセクターではありませんが、その成り立ちと役割から公共性の高い組織と言えると思います。
vLEI Credentialの種別はいくつかあり、既に世界で270万枚も発行されているLEI(Legal Entity Identifier)のVC版として、法人格に発行するLE vLEI Credentialをはじめ、その法人内の特定の役職に対し発行するOOR(Official Organisation Role)やECR(Engagement Context Role) vLEI Credentialがあります。
ACDC(Authentic Chained Data Container)の特性として、他のVCフォーマットと異なり、他のCredentialのダイジェストを保持することで、DAGの形でチェーンを形成することができる点が挙げられます。(Chainedを抜いたADC(Authentic Data Container)部分が一般的なVCと同義であると解釈すると、わかりやすいかもしれません。)
そして、vLEIではこれを持って信頼のチェーンを形成し、それを辿ると最終的にRoot of TrustであるGLEIFのAIDに行き着くと理解しています。(公開鍵を中央機関に集めるAdministrativeなTrusted Listとは異なる手法ですね。)
これらのvLEIに関する詳細は、Finema社のYanisa Sunanchaiyakarn氏が執筆した記事群を参照されることをお勧めします。Kongsuwan氏と同様に非常にわかりやすく構成・執筆されており、とっかかりとして最適です。私はまずこれを読むことで、Governance Frameworkの理解の深まりに繋がりました。
公表されているGLEIFに認定されたLE vLEI Credentialsを発行可能なQVI(Qualifed vLEI Issuer)の数は現在2社のみの模様ですが、今後vLEIが国際的な組織向けのデジタルアイデンティティのデファクトスタンダードとなる可能性に注目しています。
3. おわりに
少し上記でも述べましたが、この分野の呼称に関して、個人的に興味深いと思う点を一つお話ししたいと思います。「自己主権型アイデンティティ」や「分散型アイデンティティ」という呼称は主流派の一部から敬遠されがちのように見受けられます。これは(特にこと日本では顕著に)、「分散型」がW3C DIDsやブロックチェーン、しまいにはweb3と、実態とは異なる事象と安易に結びつけられてしまうからではないでしょうか。確かに、これらの呼称は先発のオルタナティブグループから提唱された印象が強いです。そしてこの影響もあってか主流派はこの分野をVerifiable CredentialsやWallet Modelと呼ぶことが多いように思います。
この点については、私は歴史好きなのですが、日本神話や伝承に登場する神様、例えば有名な大国主や饒速日が、登場する書物や祭られる神社によっていくつかの異なる名を持ち、神話や伝承の内容も異なることと似ていると感じます。これは書き手の所属するグループやポジションが影響を与えているからだと思いますが、古来も現在も「人」が行うことに対するアナロジーを感じ、非常に面白いと感じています。
ちなみに、私が自信を持ってタイトルに「分散型アイデンティティ」と付けた理由は、今年聴講したEuropean Identity Conferenceにおいて、主流派も全く問題なくDecentralized Identityと呼称していたからです。つまり、このヨーロッパの大きな舞台では、Decentralizedという言葉が「HolderへのCredentialの集中化」を意味するものとして、全体で共通認識がとれていたように感じられました。
それでは本稿のポイントをまとめます。
- どの技術的流派でもパブリックセクター(またはそれに準じる団体)が主導し、プライベートセクターと協働する形でユースケースが形成されていく。
- 短期的には技術的流派の勝敗は決着済みで、普及フェーズへと移行している。
- メインストリーム: Wallet Attestationがホットトピックになっている。
- オルタナティブ: 長期的な視点で潮流に変化を起こすか注目していきたい。
- W3C DIDsとブロックチェーンの存在感は低下しているように思える。
以上がこの分野にすみっコぐらしするものとして、各流派の熱い想いと取り組みに敬意を払い多大な感謝を込めつつ、なるべくどこにも肩入れせずフラットな姿勢を意識して考察した結果です。違う見方の方もいらっしゃると思いますが皆様はどうお考えでしょうか。
この記事を書いた目的は、読者が分野全体の中でのその立ち位置を把握できてからのほうが、KERI Suiteの技術的試行の記事がわかりやすくなると思い立ったからです。したがいまして次回の私の記事では、KERI Suiteを実装するオープンソースを使い、各々にAIDやKEL、Witnessを持つエンティティを2つ用意し、IPEX (Issuance and Presentation Exchange Protocol)に則りVerifiable CredentialsとしてACDCを発行する模様を共有したいと思います。
どなたかのお役に立てたならば幸いです。
追記(2024/11/13)
この考察を時系列で図化しました。
