IIW (Internet Identity Workshop) の Verifiable Credential チケット

デジタルアイデンティティ難しいです。勉強のため、アイデンティティに関する世界最大規模のワークショップ IIW (Internet Identity Workshop) に参加してみることにしました。年に2回の会合で、第32回となる今回は2021年4月20日から3日間のオンライン開催です。アンカンファレンスと呼ばれるスタイルが採用されています。あらかじめプログラムが決められる通常のカンファレンスとは異なり、毎朝 Opening Circle という場でその日のプログラムを参加者たちが話し合いながら決めていくようです。

開催まで一週間を切った4月16日、IIW の事務局から開催案内メールが届きました。ワークショップでは QiqoChat という交流システムを使うようで、開催前に参加登録と動作確認をしておくようにとの指示でした。

QiqoChat への参加登録には2通りのやり方があるようです。1つ目は “Personalized Link” で、メールに含まれる URL (受信者を特定する識別子付き)をクリックして登録する、よくあるやり方です。

2つ目の方法が本記事の本命で、その名も “Verified Credential Ticket” です。”Verified” とありますが、これはきっと今はやりの Verifiable Credential (VC) でしょう。日本でも昨年11月の #idcon vol.28 で実験的にチケットとして利用されていました。今回も勉強のために VC のチケットを取ってみましたので、参考までにその過程を共有します。

Verifiable Credential とは

本題に入る前に Verifiable Credential (検証可能なクレデンシャル) について簡単に紹介します。

「クレデンシャル」は多様な使われ方をする言葉ですが、ここでは運転免許証、社員証、卒業証明書のような、その持ち主が何らかの資格や属性をもつことを第三者が保証する文書をクレデンシャルと呼びます。例えば運転免許証は、持ち主が自動車を運転する資格をもつことを都道府県公安委員会が保証する文書です。

Verifiable Credential はデジタル化されたクレデンシャルです。データモデルは W3C 勧告になっています。デジタル署名やゼロ知識証明といった暗号技術を活用することで、紙でできた従来のクレデンシャルよりも高いセキュリティやプライバシ保護を実現するという嬉しい特徴があります。例えば氏名や生年月日を隠したまま運転資格をもつことだけを証明したり、生年月日を隠したままで年齢が20歳以上であることを証明したりできます。前者は Selective Disclosure (選択的開示) と呼ばれます。最近はワクチン接種証明書 (ワクチンパスポート) への応用が期待され、国際的な注目を集めています^[1]参考: CCI (COVID-19 Credentials Initiative), VCI (Vaccination Credential Initiative)。

今回は QiqoChat の中の IIW 専用スペースに入るためのチケットが、この Verifiable Credential (VC) を使って実装されたようです。私 (チケットの持ち主) が、IIW の参加者であることを、IIW 事務局が保証するためのクレデンシャルです。そこまでプライバシ保護が要求される状況ではないかもしれませんが、実験として面白いと思います。

登場人物とチケットの流れを簡単に図示します。

メインの登場人物は、VC チケットを発行する IIW 事務局、発行された VC チケットを保持する私、私が提示したチケットを検証する QiqoChat の3者です。ブロックチェーン (Verifiable Data Registry) は発行者 (今回は IIW 事務局) の識別子や公開鍵を格納する場所で、具体的には Decentralized Identifier (DID) のためのものですが、本記事では説明を割愛します。

チケットの発行と受取

まずは IIW 事務局から VC チケットを受け取ります。IIW 事務局から受け取ったメールをモバイルデバイスで読んでいるか、それとも PC で読んでいるかでやり方が変わります。モバイルデバイスの場合は、メール内のリンクをクリックするとデバイス上で「ウォレット」と呼ばれるアプリケーションが起動し、登録処理が始まります。一方、PCでメールを読んでいる場合は、メールに埋め込まれた QR コードを「ウォレット」でスキャンすると処理が始まるようです。どちらもあらかじめ「ウォレット」のインストールが必要です。候補として Esatus, IdRamp Passport, Lissi, Trinsic の4 つが挙げられていました。いずれも Android と iOS の両方に対応しています。

私は実験用に入れていた Trinsic Wallet を使いました。メールは PC で受け取っていたので、PC 上に表示した QR コードを Trinsic Wallet でスキャンしました。

ちなみに Trinsic Wallet は Verifiable Data Registry として利用するブロックチェーン(台帳)を選択可能になっていました。今回は Sovrin Network のメインネットに設定したところ、問題なく動きました。

ここから VC チケットが私のウォレットに入るまで、私とウォレットと IIW 事務局 (が使っている idRamp のサーバ) の間で、以下のようなやり取りが行われます。ウォレットと idRamp 間の通信は直接見えなかったため、想像して書いています。Trinsic ウォレットで動くことが確認できたので、ここには Hyperledger Aries の Issue Credential Protocol が使われていると仮定しています^[2]参考: Trinsic のドキュメント。

メール内の QR コードには https://oob.idramp.com/(32桁の16進数) のようなリンクが含まれています。

ウォレットを使って QR コードをスキャンすると(1)、ウォレットがこのリンクにアクセスし(2)、Issuer である idRamp のサーバから Credential Offer を受け取ります(3)。Credential Offer は「こういったクレデンシャルをあなたに発行しようと思うけど、良いですか？」という意味合いのメッセージです。これを受けたウォレットの画面上には、クレデンシャルの内容と受入可否を尋ねるボタンが表示されます(4)。(ここ、スクリーンショットを撮り忘れました)

クレデンシャルは Event Attendee という名前で、以下の9属性を含んでいます。

• Email: 事前に登録したメールアドレス
• First Name: 事前に登録した名
• Last Name: 事前に登録した姓
• Company: 事前登録時に社名を記載したつもりでしたが . (ドット) になっていました
• Event Name: IIW 32
• Event Identifier: iiw32
• Issue Date: 04/20/2021
• Event Date: 04/20/2021
• Attendee Type: Participant

内容に問題ないことを確認したので(5)、ウォレット上で ACCEPT ボタンを押します(6)。するとクレデンシャルがウォレットに格納され、Issued 2021/04/16 と印字されます。

この裏ではウォレットと Issuer の間で、プロトコルに従った Credential Request(7) と Credential 発行(8) が行われたものと想定しています。おそらくCamenisch-Lysyanskaya (CL) 署名方式を使って、コミット (秘匿化) された link secret と上の9属性に対する署名が生成されたものと思います。

これで、IIW 事務局の発行してくれた VC チケットが、めでたく私のウォレットに格納されました。

チケットの利用

無事に VC チケットが手に入ったので、これを持って QiqoChat に向かいます。この後の一連の流れをシーケンス図にしておきます。

VC チケットで入場するには、QiqoChat に用意された専用ページ(https://qiqochat.com/authorize_personal_identity_solutions_event?event=iiw32) を使うようです。PC でこちらにアクセスすると(1,2)、QiqoChat から idramp.com にリダイレクトされました(3,4)。先程チケットを発行してくれた idramp が、ここでは ID プロバイダ (IdP) を兼ねるようです。具体的には以下のような URL にリダイレクトされます。

https://prod.idramp.com/indy/idp/(乱数っぽい文字列)/(乱数っぽい文字列)?returnUrl=%2Foauth20%2Fendpoint%2Finit%2F(乱数っぽい文字列)

OpenID Connect かと思いきや、そうではないようです。

IdP からは、以下のような QR コード付きの画面が返されました(5)。QR コードの中身はクレデンシャル発行のときと同じような https://oob.idramp.com/(32桁の16進数) という URL でした。

ここから PC は IdP の https://prod.idramp.com/api/v1/indy/status/(乱数っぽい文字列)/(乱数っぽい文字列) に毎秒アクセスし、サーバ側の状態が変わるのを待ち続けます(6,7)。

表示された QR コードを手元のモバイルウォレットでスキャンすると(8)、ウォレット上に Presentation の同意確認が表示されます(11)。

この裏ではウォレットと IdP の間で Hyperledger Aries の Present Proof Protocol が動いているものと思います(9,10)。ここも見えないので想像ですが。

ウォレット上では各属性について提示するか否かを選択できます。これが噂の Selective Disclosure (選択的開示) ですね。デフォルトではすべて開示になっていますが、例えば Attendee Type のところを押すと、開示と非開示を切り替えられます。

折角なのでいくつか隠してみても良かったのですが、今回は真面目に全部開示しました(12,13)。するとすぐに proof 成功の表示が出ます。思ったより早いです。(画面に表示されている Masterid や Prooforcreditcard は今回とは無関係です)

裏ではウォレットと IdP の間で Hyperledger Aries の Present Proof Protocol に則った Presentation と検証が行われたと想定します(14-16)。おそらく CL 署名に付随するゼロ知識証明が使われ、署名値や一部の属性を隠しつつ署名の有効性を証明して検証されたものと思います。

すると、毎秒ポーリングしていたブラウザに IdP からリダイレクトが返り(17)、ブラウザ、QiqoChat、IdP の間であれこれ走った後(18-23)、めでたく PC 側に QiqoChat の初期画面が表示されます。

説明を飛ばしてしまった18から23の処理を振り返ってみます。ブラウザは IdP へのポーリングを終えると(17)、IdP の別ページにリダイレクトされます(18)。IdP 訪問時に returnUrl として与えていた場所です。具体的には /oauth20/endpoint/init/(32桁の16進数) でした。

ここから今度は QiqoChat にリダイレクトされます(19,20)。具体的には https://qiqochat.com/idramp_authorization_events/callback?code=(文字列) です。(Authorization Code Flow 的な動きに見えますが state 等がないですね。そもそもどうやってこの callback 先を知ったのだろう)

この後、裏では QiqoChat が IdP にアクセスし(21)、IdP が私の Presentation から抽出した属性を ID Token 等の形に変えて渡してあげて(22)、QiqoChat が私の属性を把握(23)、という動きが走っているものと思います。ここも私の想像です。

まとめ

個人的には VC を使っただけで満足してしまいましたが、少し冷静になって何が嬉しかったのかを考えてみます。

Verifiable Credential の利点の1つは、Issuer と Verifier の間に必ず利用者 (Holder) 本人が介在し、利用者に関する情報の流れを利用者自身が制御できるようにすることで、Issuer や Verifier による利用者の行動追跡を難しくする点にあると思っています。今回は Issuer も Verifier も同じ IIW 事務局 (実際には idRamp) なので利点が分かりにくいです。本当は QiqoChat 側で Verifier の機能を備えて、Presentation の検証を idRamp に任せないのが VC の想定しているモデルに沿うように思いますが、すべてのサイトが Verifier 機能を実装するのも大変ですね。

ただ、後になって思ったことですが、今回のケースでも Selective Disclosure を使ってメールアドレスと氏名を隠せば、presentation の際に idRamp (Verifier) に私の素性を特定させず、ただ IIW32 の参加者であることだけを示すことができますね。その状態で QiqoChat に連携してくれるようなら、QiqoChat にメールアドレスも氏名も明かすことなく、匿名の IIW32 参加者として振る舞えたのかもしれません。今回は既に全属性を開示してしまったため確認できませんが。

現在 OpenID Foundation で改訂が進められている Self-Issued OpenID Provider (SIOP) や、その改訂を待って本格的に議論が再開されるという DID-SIOP も、今回のようなユースケースには深く関わってくるのではと思います。引き続き勉強します。