こんにちは、富士榮です。
なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。（往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする）
※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・
また機会があればdidconでも開催してじっくりお話させていただこうと思うので思うがままに書いた乱文ですが、こんな感じかと。（いうまでもありませんが、完全に私見です。私が関与している各種団体や事業者には一切関係ありませんので悪しからず）
- まだ意外と誤解されているが分散型「アイデンティティ」ではない
- DIDはDecentralized "Identifiers"でありDecentralized "Identity"ではない。
- なぜならIdentity=Set of attribute（ISO/IEC 24760-1 2019）なのでDecentralized "Identity"という話であればOpenID ConnectのDistributed Claimsの方がよっぽど分散されている。
- では、何が分散されているのか？というと識別子（Identifier）と関連するメタデータ（Document）が分散台帳等の上（これも特にブロックチェーンと明確に規定されているわけではなく、現に全然分散されていないDIDもある）にデプロイされることで単一事業者等への依存度をさげられたり、関連して相対的にではありますが可用性などを気にする必要性が少なくなったり、というレベルの話。
- というか、W3Cが規定しているのはDecentralized "Identifiers"だし、決めているのは識別子とメタデータ（DID Document）の書き方くらい。
- 自己主権型アイデンティティは幻想？
- そもそもデータに関する主権ってなに？という話で、先にも書いた通り目的語が不明確な中でDecentralizedが分権型なのか、分散型なのか、非中央集権型なのかもぼやけている中で何を持って自己主権なのか？というレベル。
- パブリック/パーミッションレスな分散台帳に識別子（Identifier）と署名検証に使う公開鍵を含むメタデータ（DID Document）を公開することで特定の事業者が当該のエンティティに関するデジタル上での生殺与奪に関するコントロールしずらくなる、ということを言いたいんだ、ことはわかるんですが、それが果たして「自己主権」に繋がるのか？と言われるとうーむ、という話。
- もう一つはVerifiable Credentialsの持つポータビリティという性質の話。後でも触れるがDIDをうまく使うことでIdPとRPの結合度を下げることは確かに可能で、結果としてVerifiable CredentialsをWalletと言われるスマートフォン等で動作するソフトウェアの中に格納して個人が持ち運ぶことも可能、という意味ではIdPからの独立性＝自分で自分のアイデンティティをコントロールしている感を醸成しやすいという点は認めることはできる。
- 結局のところ、唯一言えるのは自己主権型アイデンティティというのは思想であり、テクノロジとは切り離して考えるべきだ、ということ。たしかに現状のFederationを考えると相対的に分散台帳と紐づいたDIDと関連する鍵によって署名されたVerifable Credentialsは事業者の「支配」から逃れられている気にさせてくれる。
- ちなみにこれは最も重要な点かも知れないが、DIDが「did:メソッド名:固有の識別子」という形式をとっている以上、メソッドを跨いでDIDや署名済みのVCを持ち運ぶ（引っ越す）ことは事実上不可能である点は見逃してはいけないと思う。
- Verifiable Credentialsが本命？
- 今年度私も少しだけお手伝いさせていただいている内閣官房Trusted Web推進協議会のホワイトペーパーにも記載の通り、暗黙的な信頼から検証に基づくExplicitな信頼へという流れはDXの要になると思われる。まさにDon't trust, Verifyという言葉が全てを物語っている。
- ただ、ここで解決しておかないといけないのはSAMLやOpenID ConnectのAssertionへのデジタル署名との違い。確かにCOVID-19のワクチン証明にVerifiable Credentialsを使ったことに新しさはあるけど、実態はデジタル庁の自己署名を打っただけのJSONなので、耐改竄性という意味においてはSAML AssertionやOpenID Connectのid_tokenと何ら変わらない。（もちろんFHIRの標準化されたSchemaをPayloadに使うという意味においてアプリケーションレイヤでの相互運用まで踏み込んだ点では非常に重要なアプローチだとは思う）
- では、DIDとセットにする意味は？という話だが、実際問題としてメリットはゼロではない。どういうことかというと、署名検証をするための公開鍵をjwks_uriなどで公開しているケースに比べて、こんなメリットがある。
- 事業者がIdPの可用性をそれほど考えなくて良い（IdPが落ちていても分散台帳上にDID Documentを公開してしまえば、コンロトーラビリティは下がるが相対的に可用性は向上することが多い）
- OPがシャットダウンされた時、ユーザが署名付きクレデンシャルの真正性を証明できなくなる、という事態はなくなる
- とはいえ、よくある話として署名アルゴリズムの危殆化の話は当然あるので、（相対的に単一事業者の都合が可用性に与える影響度合いが少ないと言える）分散台帳に公開鍵を置いているからと言って半永久的にVerifiiable Credentialsの署名を信頼できるかというとそうではなく、実運用では少なくとも数年に一度はVCの再発行は必要になると思われる。そうなるとIdPの事業継続性の観点でVCが優位というロジックは非常に限定的（つまり、少なくともIdPが潰れても数年間は資格証明が可能というレベル）だし、いわゆるソーシャル・インクルージョンの文脈で語られる国家というIdPによるネグレクトに対する銀の玉にはなりそうにもない。
- VC発行者に関する信頼は難しい問題
- VCの発行に際して発行者は自身のDIDにに紐づく秘密鍵で署名するわけなので、そのDIDは誰なのか？信頼できるのか？という点が重要になってくる。
- 実世界のビジネスモデルを考えるとDNSの持つ分散ガバナンスモデルに依拠するのが落とし所、という形でwell-known did-configurationがMSでもMattrでも実装されているが、DID/VCのモデルの外に依存している段階で分散とか分権とかいうキーワードは虚しく感じられるのは自分だけではないはず。
- そして、結局は一番怪しいのがDIDからDID DocumentをLookupするためのResolverの信頼性。もちろんUniversal Resolverを含めオープンな実装は透明性という意味である程度信頼はできるとは思うが、結局はDriverの実装者と実インスタンスを動かしている事業者の誠実さを「信頼」するしかないのが現状。
- いくらVerifiableだったところで信頼されるとは限らない
- そもそもTrust FrameworkってITの世界でクローズできるものではない。
- 実際、いくらデジタル署名されたデータセットは改竄されにくい、と言ったところで人間はヒューリスティックな生き物で「見たことがある紙やプラスチックの物理的な身分証明書」を対面で提示されることにはかなわない。
- これはDXの本質的な話で、Digitization〜Digitalizationなど段階を定義するのは良いが、現実論としてDigitizationとDigitalizationの間には大きな溝があると思う。みんなPDFとかExcelが大好きだし、最後の手段で紙に戻せば業務継続できると思っている段階で、最初から紙を前提としないDigitalizationの段階へは永遠に進めないと思う。
- そういう意味ではVerifiableという特性をフルに活かすことのできるユースケースをなるべく早く見つけることが最大のミッションなのかも知れない。この辺りは先にも触れたTrusted Web推進協議会が大きな役割を果たすことが期待される。
- KYCというか本人確認・身元確認との相性はそれほど良くはない
- 結局、Identity Proofingの本質はNIST SP800-63Aでいうところの、
- Resolution
- Validation
- Verification
- というステップによって構成されており、この中でVCが役に立つのはValidation（提出したエビデンスの真正性検証）。でも良く考えるとValidationの本質はオーソリティへの照会（この辺りは身元確認の「元」という文字にも現れている）なので、Evidenceが改竄されていないことの証明だけでは不十分。
- 確かにRevokeに関するスペック（Status List 2021）も標準化が進んできているので有効性確認はできるようになるとは思われるが、Evidence発行元におけるKYCプロセスの信頼性まで担保できるわけではないし、オーソリティの信頼性の方がEvidence自体の耐改竄性よりも重要な世界。
- また、Verification（Evidenceに記載のエンティティとEvidence持参のエンティティの同一性確認）ができるわけではない
- となると、身元確認ではなくOpenBadgeがやっているように資格証明程度に使うのが現実的だと思われる。
- 結局はIdPとRPの結合度を下げることが可能、というのが最大のメリット？
- こうなるとOpenBadgeではダメなの？という話はあるが現状のOpenBadgeのほとんどがSigned型ではなくHosted型（Issuerへの問い合わせにより真正性・有効性を検証する方式）であることを考えると、システム間の結合度を考えると一定の優位性はある状態（少なくともSigned型が普及するまでは）
- つまり、結局のところシステム間（OPとRPの間）の結合度をさげるためのもの、という使い方が現状ではベストなのでは？と思われる。
- 事実、去年のIIWでのユースケースに関するディスカッションをしている時に私が話した、大学のID基盤の管理負荷（ライセンス・インフラのサイジング・可用性）を下げることができるのでは？というのが一番響いたっぽい。（少なくともVittorioあたりには）
- 標準化の実際はどうなっているのか？
- まだまだカオスに見える。Hyperledger勢がDecentralized Identity FoundationとかTrust over IP Foundationとかで推しているDIDcommや、OpenID FoundationでやっているSIOP v2やOIDC4VPとか。
- そもそも論、VCにJSON-LDを使うのかJSONで行くのかも議論が尽きないポイント。
- そんな中、いろんなベンダがビジネスとして立ち上がってきており微妙な段階の仕様を実装してサンプルコードとかを公開するので、世の中の開発者が真似をしてさらにカオスな状態が出来上がり、標準化とは？という世界が出来上がりつつある。
- ゼロ知識証明（ZKP）、選択的開示（Selective Disclosure）が本命？
- そもそもゼロ知識証明に関してはMSが買収したuProveとかIBMのIdeMixとか昔から研究されてきている領域だけどまだまだ実用化には遠いのが現状。（そういえば10年以上前にuProveのテストインプリがされたWindows Identity FoundationのPrivate Previewのテストをやっていたのが懐かしい）
- またZKPとSelective Disclosureはごっちゃに語られることも多いけど、結局のところ必要なのはSelective Disclosure。この辺はBBS+とか頑張ってるがまだまだ課題はあり（隠せる範囲が限定される、など）、早稲田の佐古先生とかIIJの山本さんが拡張提案をしていたりするのでこの辺りは要ウォッチ。
- よく言われる物理世界ではできなくてデジタルの世界でできるようになるといいよね、と言われるバーに入る時の年齢確認に免許証を出すと年齢以外の情報までガードマンに知られちゃう、という話への対応はこの辺りのテクノロジの成熟と実装に期待はされている。ただ、本当にガードマンに年齢以外に名前を知られて困るのか？という話はあるので、ユースケースについてはもっと議論しないとダメだと思う。
- 結局何か世の中の課題を解決できたのか？
- よく言われるものとして、
- プライバシー
- 検証可能性
- があるが、上記を見ている結局そこまで解決に至っているとはいえない。
- それよりも、上記に書いた通りOPとRPの間の結合度を下げることによる管理面やインフラ的なコスト削減が一番のメリットになるのでは？
と、色々書きましたがテクノロジーとしては非常に面白く今後世界を変える可能性のあるものだと信じているので引き続き研究していきたいと思います。
0 件のコメント:
コメントを投稿