DID/SSIについて、考えてみる

●背景：

前回の記事では、オラクル問題について整理をした。
認証のオラクルを担保する必要性について言及したわけだが、認証×ブロックチェーンということで、近しいテーマであるDID/SSIについて今回は整理してみようと思う。

●DID/SSIとは

DID、SSIそれぞれを直訳すると、以下となる。
DID：Decentraized IDentity　：分散型ID
SSI：Self Sovereign Identity　：自己主権型ID

では、両者の違いは何かというと、明確な定義上の違いはないように思う。あえて違いを説明するのであれば、DIDは「非中央集権管理」であることに重きを置いており、SSIは「自己主権であること、つまり、自身の意志により情報開示を自由に制御できること」に重きを置いている。

IDの管理方式の変遷については、以下のように辿っている。
・ID第一世代：各企業サービス毎にIDをバラバラに登録する
・ID第二世代：SNS認証など、プラットフォーマーのIDを共通IDとしてサービス登録する（実態としては、プラットフォーマーから各企業サービスのID登録に必要な情報が連携され、ID第一世代と同様のIDが各サービス毎に作られている）
・ID第三世代：DID/SSI。ユーザはユーザ情報を自身の端末などで管理し、必要な相手に必要な情報を必要なタイミングで提示する。

現在は、ID第二世代からID第三世代への移行過渡初期である。（本当に第三世代へ移行するかはわからない）

●ID第一世代・ID第二世代の課題

ID第一世代・ID第二世代の課題については、以下のようにまとめられていた。

SSI（自己主権型ID）とは？デジタル時代にSSIが求められる背景と仕組み - dataway

Sovrin Foundation の議長を務める Phillip J. Windley 氏は、デジタル世界のアイデンティティに対して5つの問題点を提示している。

The Proximity Problem（近接問題）
オンラインのやりとりにおいては、取引相手がどのような人なのか、そもそも人なのかすら分からないため、不正の余地がある。オフラインの場合は対面でのやりとりとなるため、不正の余地が少ない。

The Scale Problem（スケール問題）
Google や Facebook 等のソーシャルログインが一般に利用されているが、いつ仕様が変わるかも分からないような外部サービスの導入に積極的ではないサービスもあり、1つのIDによるスケーラビリティは限定的になってしまう。

The Flexibility Problem（柔軟性問題）
現状のアイデンティティ関連ソリューションは、スキーマやアトリビュートの仕様が限定的で柔軟性に欠けている。

The Privacy Problem（プライバシー問題）
個人識別子を元にデータはコピーされ企業保有のストレージに集積されることになるが、そのセキュリティが100％守られているとは限らない。

The Consent Problem（同意問題）
個人の同意なしにデータの提供がされてしまうことがある。

上記５つの課題点について、それぞれ理解を深掘りしてみる。

①The Proximity Problem（近接問題）
オンラインのやりとりにおいては、取引相手がどのような人なのか、そもそも人なのかすら分からないため、不正の余地がある。オフラインの場合は対面でのやりとりとなるため、不正の余地が少ない。

これは、ユーザ同士が取引・コミュニケーションをとるようなサービスを考えた時に、相手が信頼に足る人間かの判断が不可能であり、サービス提供者のチェックに依存せざるを得ない　ということだ。
例えば、KYCが緩いマッチングアプリにネカマや業者が紛れるような問題がこれに該当する。フィッシングサイトや、偽のECサイトで市場価格よりもかなり安い価格の商品を売り、実際の商品は送らないというような詐欺サイトもこの問題に該当するだろう。

②The Scale Problem（スケール問題）
Google や Facebook 等のソーシャルログインが一般に利用されているが、いつ仕様が変わるかも分からないような外部サービスの導入に積極的ではないサービスもあり、1つのIDによるスケーラビリティは限定的になってしまう。

上記の問題については、納得感が薄かった。
Google認証の仕様を、過去互換性なく頻繁に変更することなどは考えづらく、認証部はもはや部品化されているため、移行もハードルが高いものとは思えない。

③The Flexibility Problem（柔軟性問題）
現状のアイデンティティ関連ソリューションは、スキーマやアトリビュートの仕様が限定的で柔軟性に欠けている。

これは、既存のID関連ソリューションに定義できるID情報に柔軟性がないため、活用できるシーンが限定されてしまっているということだ。
例えば、名前、顔写真、生年月日、住所などの特定項目のみ定義できるが、その他属性情報や、趣味嗜好など情報が、IDを利用する側のサービスとしては必要な場合もあり、限定された項目のみを提供するIDサービスだと使えないという場合が発生しえる。

④The Privacy Problem（プライバシー問題）
個人識別子を元にデータはコピーされ企業保有のストレージに集積されることになるが、そのセキュリティが100％守られているとは限らない。

Googleなどのプラットフォームに登録した私の名前・メールアドレス等の情報が規約通りに守られるとは限らないということだ。Facebookの情報流出事故などは記憶に新しい。Facebookほどの世界の時価総額Top10に入るような超大企業でさえもデータを守りきれないということは、このような情報流出はどの企業でも起こり得るということだ。
各企業は膨大なコストをかけて、個人情報管理の仕組みと体制を整え、プライバシーマークの取得により、企業の社会的信用を得ようとする。
それでも、プライバシーマークを取得している大企業からの個人情報流出は定期的に起る。

⑤The Consent Problem（同意問題）
個人の同意なしにデータの提供がされてしまうことがある。

これは、例としてリクナビから企業に対してユーザの内定辞退率をユーザ同意なしに提供していたことが挙げられる。

●DID/SSIで何が嬉しいのか、何が解決できるのか

まず、前提として、DID/SSIが広がった世界がどのような世界なのかを簡単にイメージしてみる。

DID/SSIが広がった世界では、各個人が自身のIdentity情報を保持する。
Identity情報には、名前、住所、年齢などの基本情報に加え、運転免許証、保険証、マイナンバー証などの各種公的証明情報が紐付き、また学位証、TOEICの点数、民間発行の技術証明書（Oracleゴールドとか）も紐づく。また、現在は企業の中に閉じている勤務実績情報なども努めた企業のお墨付きで紐付けるようなことも考えられる。
これらのIdentity情報が、個人に紐づくウォレットで個人の手元で管理される。
個人の手元（スマホなど）で管理する場合、当然そのIdentity情報のハッキングのリスクがあり、ウォレットの管理のセキュリティも考える必要がある。例えば、ウォレットからのトランザクション発行は常に生体情報に紐付けた秘密鍵が必要なものとし、その秘密鍵へのアクセスは生体情報が必要とするような管理だろうか。

ユーザは、企業が提供するサービスを新たに利用したいと考えた時、企業が要求する個人情報項目を自身のウォレットで管理するIdentityから情報を抽出して共有する。この時、A：「個人情報自体を渡す」のか、B：「自身が確かに該当の情報を持っていてその企業のサービスを利用する上での条件を満たしていることの証明を渡す（ゼロ知識証明）」のか、どちらが良いのだろうか？

ここで、A：「個人情報自体を渡す」だと、その個人情報は結局企業側で管理されることになり、先に挙げた①〜⑤の課題の解決にはならない。

一方で、Bの場合、つまり個人情報を一切渡さない場合、本当に利便性を落とさずにサービスを利用することができるだろうか？DXの文脈では、ユーザの行動情報・属性情報をなるべく吸い上げて、サービスの改善や、ユーザの行動パターン・嗜好にマッチさせたサービスを提供をしてゆこうというのがよく言われることだ。
個人情報は渡さず、企業にはより良いサービスを提供してもらうには、ユーザは個人を特定する情報（氏名、住所、電話番号など）は企業には渡さず、逆に個人を特定できない属性情報・行動情報は許諾の下、積極的に提供する、という形だと思われる。

結論、B：「自身が確かに該当の情報を持っていてその企業のサービスを利用する上での条件を満たしていることの証明を渡す（ゼロ知識証明）」があるべき姿だと思う。

上記のような世界観が実現できた場合、先に挙げた現状のIdentity管理における各種課題は解決できるだろうか？

①The Proximity Problem（近接問題）
DID/SSIが広がった世界では、各個人・法人が自身のIdentity情報を保持する。
個人間の取引、個人法人間の取引、法人間の取引において、自身のIdentity情報が取引に必要な条件を満たしていることを証明（ゼロ知識証明）した上で、取引を実施することができる。
つまり、①の問題はクリアだ。

②The Scale Problem（スケール問題）
スキップ。現状でも問題になっているように思えなかったので。

③The Flexibility Problem（柔軟性問題）
Identity情報は、柔軟性（拡張的にIdentity情報を付加できる）を持つように設計するべきだ。これはDIDの設計の問題なので、設計次第で柔軟性を持たせることは可能なように思う。

④The Privacy Problem（プライバシー問題）
ゼロ知識証明による、条件を満たすことの証明をベースにすれば、企業側にそもそも個人情報が渡らないため、クリアだ。

⑤The Consent Problem（同意問題）
企業側に個人情報がそもそもなければ、他に横流しもしようがない。クリアだ。

●まとめ

DID/SSIに対する思考の深掘りをしてみた。
DID/SSIの形に、デファクトスタンダードはまだなく、上記した内容はあくまで私が思考する中でまとめた一見解である。
今後、DID/SSI関連のプロジェクトの動向を追いながら、必要に応じて本記事もアップデートしていこうと思う。