ケンタロウのメモ

内容薄めです。

自己主権型IDってなんなのか

全然いまさらのトピックだとは思うけど
ちゃんと自分の言葉で理解するためのメモ。

僕の頭の中ではIDといえばフェデレーションモデル というところで
止まっているので、アップデートのための勉強です。

自己主権型IDとはなんなのか

答えはここにだいたい書いてあったので引用

自己主権型アイデンティティ(Self Soverreign Identity /SSI)とは
「個人は、管理主体が介在することなく、自身のアイデンティティを所有しコントロールできるべきである」とするデジタル・ムーブメントを表す言葉。

そうか、SSIはムーブメントのことを指すのか

この図がめちゃくちゃわかりやすい

フェデレーションモデルだと、お買いものしたいAくんがお店でレジに行くと
お店がIdPに問い合わせ → IdPはAくんに「本当にAくんだよね?」と確認 → Aくんと確認できたらお店にその旨を連絡 → お店はAくんにサービスを提供

という感じだったのが

SSIモデルだと、お買いものしたいAくんがお店でレジに行き免許証を見せるだけで
お店はその免許証(の発行元である警察)を信頼し、Aくんにサービスを提供する

ということらしい

フェデレーションの何がだめで、SSIは何を解決するのか

IdPが認証を一元的に取り扱い、サービス(RP)がIdPに問い合わせるモデルだと以下のような問題がある

  • IdPがシングルポイントとなる

シンプルに、IdPに認証の問い合わせが集中するのでボトルネックになり得る
構成変更などでサービス停止したいと思っても影響が大きすぎたり、IdP側ではもはやRPが被る影響の判断ができないのはあり得ると思う

  • プライバシーの課題

IdP側や、あるいはRP側が結託すると行動把握ができてしまう
確かにある主体がいつどのデバイスからどのRPにアクセスしたか、それを繋げることで行動をうっすら追うことはできてしまいそう

  • IdPとRPの情報が非同期

IdP側でステータスの変化があっても、RPはユーザがログインした契機でした情報取得ができない
IdP側でアカウント侵害があった際、緊急的にRPに伝達することを目的にSharedSignalsFrameworkというフレームワークが現在整備されているので
こういう仕組みがあれば課題は少しずつ解決するかもしれない

  • ユーザから見てIdP運営事業者が信用できない

これはあるんだろうか?でもユーザはRPの提供するサービスを使いたいのであってIdPを自分で選んだわけではない
得体の知れないIdPに本人確認に必要な個人情報を渡すのは嫌かもしれない
登録時のKYCをIdPに任せることにもなるので、IdPのテキトウな本人確認により悪意のある第三者にアカウントを侵害され、なりすまされるリスクもあり得るかもしれない


なんとなくここまでは理解

では、SSIだと何が良いのか?


SSIは免許証、具体的には生成した識別子や認証のための鍵を自分のお財布で管理し、必要に応じてサービス側に提供できる、という考え方。

以下2つの特徴がある

  • ID情報の利用可否が特定事業者(旧来のIdP事業者のような)に依存しない

IdPの場合だと、IdPが急にサービスを打ち切ると該当IDが使えなくなるリスクはあった
しかし、SSIだと自分でIDを管理しているのでそういうリスクはない。

例えば自国を追われた難民の人が有効な身分証明書をもっていない場合に、国に依存せず自身でアンデンティティを証明できるとして活用が期待されているもの

  • ID情報の管理権限が個人にある

IdPの場合だと、個人の情報がどのように扱われているかはブラックボックスだが、SSIなら自分の意思で制御ができる


2つの特徴はこちらから引用
www.nri-digital.jp


これらを実現する実装としてDID(Decentralized Identity)といって、分散型台帳技術などを用いてIDを管理する仕様が整備されているそう。
W3Cにより検討されているDIDsという仕様だと、識別子をブロックチェーンなどの分散型システムで管理する


いろいろ疑問がわく

①そもそも生成した識別子や認証のための鍵は誰が発行するのか?

②それを個人でどう管理するのか?

②なんらか識別子や鍵を管理したとして、それを提示されたRPはどうやってそのIDが正しいか検証するのか?


ちょっと理解が追いつかないのでユースケースで確認してみる

今検討が進んでいるテーマが「学位・履修履歴証明」である

出典:https://www.nri.com/-/media/Corporate/jp/Files/PDF/service/ips/technology_1.pdf


上述はDIDで実現されている

  1. 大学はDIDと関連付けられた証明書を個人に発行する
  2. 個人はその証明書をユーザエージェント(DIDに対応した証明書管理アプリ。いわゆるwalletかな?)で管理する
  3. 証明書は暗号化されたパーソナルデータストアであるIdentityHubで管理され、必要になったときにユーザエージェントを用いて第三者に必要な証明事項の提出を行う


うむ、、疑問①はこの場合大学、疑問②はDID対応証明書管理アプリで管理すると理解。
疑問③はどうなるんだろう?
例えば転職したとき、卒業証明としてDIDがついた証明書を提出したとして、会社はその証明事項が正しいかどう検証するんだろう?

図をよく見たら少し書いてあった

証明書要求者は提示された証明書の発行者及び内容を独自に検証可能



ちょうと同じ例で解説してくれているブログがあった

blog.fltech.dev

就職活動を例にとって説明しましょう。 学生 (Holder) は大学 (Issuer) から成績証明書 (VC) を発行してもらい、 就職したい企業 (Verifier) むけに成績証明書 (VC を加工した VP) を提示します。 VP を提示された企業はこの VP を見て、学生 (Subject) の成績と出身校 (Issuer) を 確認することができます。 VP の内容は、大学 (Issuer) が発行した内容であると数学的に証明されており、 詐称されていない情報として信用できるので、雇用するかどうかの判断材料になります。 本当に正しい情報かどうか、大学に問い合わせて確認する必要はありません。


うむ、、大学に問い合わせずしてこの証明書が正しいと検証する方法はVC(検証可能な資格情報 /Verifiable Credentials )の勉強がいりそう、、、


ということで次回はDIDについて勉強します、、