論文紹介 Distributed-Ledger-based Authentication with Decentralized Identifiers and Verifiable Credentials 概要
SSI周りを追ってる方には耳タコなストーリーですが、現在IdentityにおけるFederationの技術標準の一つであるOpenID ConnectはIdentity Provider（OP）が、エンドユーザーのIdentityを一定レベルで制御下においているUser-CentricなIdentityモデルです。ユーザーは、OPの利用規約およびガバナンスに同意しなければOP下にIdentityを登録・利用することができません。また、その状態ですと（Pairwiseという仕様があるものの）、ID Tokenを提供しているRelying Party（RP）同士の情報を突合されたり、あるいはOPからの情報漏えいによって、プライバシーの侵害につながる可能性もあります。OPの絶対数の少なさも、そのような懸念に拍車をかけています。そういったことを防ぐためにSSI（Self Sovrin Identity）という言葉が最近浮上していますが、
本論文はSSIとOIDCをproof of cenceptレベルで連携させることで、問題を解決しようとしています。
同時に、Verifiable Credential（VC）を使った分散台帳をつかった分散型PKIも提案されています。
分散台帳を使ったOIDCとSSIのコラボ
ざっくり言ってしまうと、OIDCでプリセットされいてる各種ClaimをCredential SchemaやClaim Definitionとして使うという内容です。そうすることで、そもそもOPへのユーザー登録が必要なくなります（といってます）（が、ログインするもとがSovrinなどに変わっただけなような気もします）。また、認証時にはVerifiable Presentation内に、各種必要なユーザー情報を登録し、pairwiseなDIDの公開鍵によって署名されたものが送られます。実際にHolderであるユーザーの代わりにウォレットがVPを送り、それが検証されたら、OIDC ClientであるWebサイトでtokenが取得できるモデルが本論文では採用されています。若干、Microsoft AuthenticatorをつかったAzure ADのVerifiable Credntial と似ている気がします。 https://gyazo.com/5dec64cbfc3da10e9fd075d4ed1b438d]
分散台帳をつかったPKIとDNS
NYMトランザクションベースのPKIとVCベースの PKIが提案されていますが、後者の方はそもそもCAが自身の公開鍵を分散台帳に登録すれば事足ります。実際には、Claim Definiton内でX.509証明書のスキーマにあわせた情報を定義し、分散台帳に書き込む設計が提言されています。
一方、DIDを台帳上に作成することになるNYMトランザクションを使う場合、従来のWebブラウザにセットされたルート証明書のようなベンダーに依存しあ方法ではなくコンソーシアム型な分散台帳のジェネシスブロックを使うことになります。そうすることで透明性と相互互換性が高まるという主張がされています。確かに、一度書き込まれたら変更が難しい（不可能ではない）公開型のpermissionedベースの台帳であればそうかもしれません。ただ、証明書チェーンになっている全証明書を保管するか、あるいはCAのみを台帳に登録するかは、設計次第となるでしょう。DNSの話はあまり語られていなかったのですが、これもbcに乗せるのでしょうか。そこら変はわかりませんでした。
以上です。全体的に既視感のある論文ですが、今後もウオッチしていきたいと思います。
おまけ: PKIのコスト
PKI運用残すとは高いといわれるが、下記のようなPKI as a Serviceもちょいちょいあります。個人的にPKIをつかった認証は、今後あまり広まらなくなる気がしていますが...