ちょっと前に情報銀行の認定事業の最後の一つだったDataSignさんのPaspitがサービス停止をしたことで通常認定がゼロになった、というニュースが界隈で出ていました。
DataSignさんのニュースリリース
情報銀行「paspit」サービス終了のお知らせ
結果、IT連盟の通常認定がゼロになっています。
ちなみにP認定はまだありますが、そもそもP認定は「「情報銀行」サービス開始に先立って立案した計画、運営・実行体制が認定基準に適合しているサービスであることを認定するものです。サービス開始後において運営・実行、改善を図り、『通常認定』の取得が条件となります（P認定の更新は不可）。」という定義なのでサービスが開始されていない（もしくはサービスを開始する前の検討段階）のものなので、実質サービスとして提供されているものではありません。なので本当にゼロ件です。
この分野はそれほど詳しいわけではありませんが、そもそもの情報銀行の意義は利用者が自分の情報を適切に扱ってくれるサービスに適切に渡すために情報銀行サービス事業者に情報を信託することで安心してサービスを利用できるようにしましょう、という取り組みだったはずです。つまり、前提として情報銀行サービスが情報を提供する先の審査を行い、適切に情報を扱うことが確認できている場合に情報を提供することでリテラシーのあまり高くない利用者を保護しましょう、という話です。これは正に信託銀行が利用者の代わりに株式や資産の運用を行うことで利用者個人が過剰に責任を負うことなく安全に資産運用ができるようにしましょう、という話と同様のもので、その意味で情報（信託）銀行だったわけです。
しかしながら、実態として情報銀行においては、この信託銀行や銀行の本来の価値である利用者に変わって比較的安全に運用を行いましょう、という部分が私たちの頭から抜け落ちていたように感じます。結果、単に個人情報をサービス事業者に預けると利子（ポイントなどのリワード）がつく、雑に言うと「個人情報を売っている」感覚に近くなっていき敬遠されていく、というサイクルだったのかな？と思ったりしています。
ちなみにこの話は本日のコラムのテーマでもある「自己主権」についても隣接する話題だと思っています。今日はそんな話です。
自己主権とユーザの責任
これまでも自己主権型IDの責任モデルについてあちこちでお話してきました。
（2019年ごろによく使っていたスライド）
また、主権？という話についても正直疑問に思っている、という話も何度もしてきました。
（昨年のOpenID TechNight、分散型ID勉強会の資料より）
この辺りを踏まえて少し自己主権型アイデンティティについて考えてみましょう。
簡単にまとめると、自己主権アイデンティティのモデルにはユーザの責任が重くなりすぎると言う点で以下の通り課題があると思っています。
- 自己主権の一番の難しさは結果的にユーザに責任を押し付けることになること
- つまり、ユーザは誰に情報を提示して良いのかを自身の責任で判断しないといけない
従来のID連携のモデルでは多くの場合RPとIdPの間で事前の信頼関係構築が前提となっていました。具体的にはIdPとRPはトラストフレームワークなどで表現されるID連携のために必要なルール（例えばRPは受け取ったID情報を適切に扱うこと、など）に基づき事前に合意している前提がありました。
そのため、IdPにアカウントを登録するユーザはIdPが連携できるRPをある程度審査していることを含めある程度納得した上でRPを使っているという建て付けになっている（利用規約とかポリシーに記載されている）わけです。
ただし、あくまでIdPがある程度担保してくれるためにはユーザが使うRPの情報などをIdPが知ることができてしまう、という点においてプライバシーリスクが指摘され、Walletを使うことでIssuer/Verifierの間にWalletが入り、ユーザ自身の意思を反映した形でID情報のやり取りが行われる＝自己主権でありプライバシー上の問題がなくなる、という話になってきたわけです。
ところが、このことによりIssuerは、Verifierを事前に審査することができなくなるわけで、Verifierが適切なのかどうかを判断できず、あくまでユーザが自身の責任でVerifierに情報を提供しなければならない、ということになってきてしまいました。
果たしてユーザは責任をとれるのか
「自己責任」の一言で済ませられるのであればそれで議論は終了なわけですが、人類はそれほど賢いわけではありません。いつまで経っても秘密鍵やパスワードの管理を人類はできるようになっていないわけで、VCがWalletに入っていても正しく管理できるようになるとは思えません。
暗号資産についても結局は事業者に管理を委託しちゃってますよね。本来はあれもBitcoinのアドレスを自分で管理することもできるはずですが、結局はカストディアンに頼るのが自然な状態になっているわけです。
と言うことでどんな対応ができるのか考えてみる
結局はWalletをIssuerが管理化に置き、VCを提示できるVerifierを制限する、などが必要になるのかもしれません。しかしIssuerが管理をするモデルになると、従来のID連携モデルでIdPが利用者が使っているRPを知れてしまう、という問題の解決にならず、Walletモデルの意味がなくなってしまいます。
となると、もう選択肢になり得るのはWalletプロバイダが提示できるVerifierを制限するという形が良いのかも知れないな、と最近は思っています。
もちろん、Verifier毎に専用Walletを使う、などの対応をしないと今度はWalletプロバイダがユーザが使っているVerifierを知れてしまうという問題が出てくる可能性もあるのですが、このモデルだと結局自己責任モデルにしかなりませんし、Verifier毎にWalletが大量にインストールされているスマホを持ちたいとは思いません。（それこそカスタムURLスキーム問題で技術的にもややこしいことになりますし）
結局はユーザが安心してVerifierにID情報を提示することができる状態を作る必要があるわけなので、ユーザが誰かを信頼して委託する（つまり信託する）必要があるわけです。Walletプロバイダのモデルだと、ユーザは従来のID連携モデルでIdPを信頼したのと同様にWalletプロバイダを信頼することになります。
こうなると、Walletプロバイダに情報が集約することは諦めるしかないわけなのですが、
- ID連携に比較してIdPへのCall home問題はなくなるのでIdPの可用性を含む全集中度合いは下げられる（別の切り口だが）
- Walletプロバイダが本当に認定済みVerifierに対してVCを提示したかどうかはわからないようにWalletを作ることはできるはず
ということは考えられるわけで、ID連携のモデルとの差別化はできそうです。
これを実現するためには、Walletプロバイダが審査済みのVerifierのみにVCを提示可能にするなどの機能を実装し、VC提示の際に許可・不許可のリストをローカルで参照する仕組みになっていればWalletプロバイダは審査済みのVerifierのうち、実際にユーザがどこに対してVC提示を行ったかは検知できないようにはできるのではないかと思います。（本当にそんな実装になっているかどうかは信頼するしかないとは思いますが）
このことで、
- ID連携におけるIdP万能という状態からは少し前進できている気はする
- 多分、次のVC関連のビジネスはWalletプロバイダが本当の意味での情報銀行（提示先の審査による安心の提供）としての機能を提供することなのかも知れない（どこまで利用者からお金を取れるかは未知数だけど）
と思えます。
この辺は引き続き皆さんと意見公開をしつつモデルを考えていけるといいですね。
投稿
0 件のコメント:
コメントを投稿