IIW #38 Day3クイックレビュー

こんにちは、富士榮です。

いよいよ最終日でした。

一昨日、昨日に引き続きIIW（Internet Identity Workshop）のクイックレビューです。

本日は、

• OID4VP Suggestions for query syntax(P.E.) simplification - Tobias, Kristina, Oliver
• OID4VC as Framework vs Profiles - Kristina
• Verifiable Credentials with BBS+ and zk-SNARKs for Predicate Proofs - Dan Yamamoto
• Learning Record - Mehesh Balan

あたりを記録しておきたいと思います。

OID4VP Suggestions for query syntax(P.E.) simplification - Tobias, Kristina, Oliver

現在OpenID for Verifiable Presentations（OID4VP）はPresentation Exchange 2.0.0（PE）を使っているがシンプルにできないか？という話です。現在、要件をDCPWGで洗い出しているそうです。

例えば、

• JWTでCBORでも使えるようにしたい
• SDにも対応できるようにしたい
• ネスト構造にも対応できるようにしたい

などがテーマのようです。

うまく、OID4VPをプロトコル、PEをクエリ言語としてモジュラー型にできるか、という議論もあります。方向性としてはPEをシンプル化してBreaking changeを極小化する形に落ち着いてくると思われます。

具体的にはinput_descriptorsの下にformat要素を作り、例えばmDocならdoctypeとしてmDL、claimsにnamespaceやdata_element_idを指定する、という形で考えているようです。

OID4VC as Framework vs Profiles - Kristina

引き続きKristinaさんのセッションです。

相互運用性を担保するために必要なこととしてあげられる、

• Definition of "mandatory to implement" element of the protocols
• Wallet invocation mechanism. Custom url scheme, etc
• Verifierにおける認証メカニズム
• Walletのクレデンシャルフォーマット
• issuerの識別とキー解決
• Holder key binding
• 暗号アルゴリズム

をプロファイルとして定義していこう、という話ですね。

これはOAuthでも行われていることでRFC6749はFrameworkでFAPIなどはプロファイル、という言い方をします。

しかし、FAPIではブラジルやオーストラリアのオープンバンキング向け、など各国向けのプロファイルが存在している状態になっています。今回のOpenID for Verifiable Credentialsはどうしていくのか？は考えないといけないところだと思います。

現在、HAIP（High Assurance Interoperable Profile）が定義され、EUではこのプロファイルを使うことになっていますが、これが全世界的に受け入れられるプロファイルとなるのか、もう少しコアプロファイルを削り出して個別の事情を含め柔軟に受け入れられるようになるか、は今後のデザイン次第だと思います。

参考までに、HAIPでは

• Protocol profile
• SIOP,OID4VP,OID4VCI
• Credential profile: SD-JWT VC
• SD-JWT VC
• JWT/CWT Statuslist
• Wallet Attestation Scheme
• Attestation based client authentication
• Basic choices
• Custom scheme
• Issuer key resolution
• Crypto suite

あたりが決められています。

Verifiable Credentials with BBS+ and zk-SNARKs for Predicate Proofs - Dan Yamamoto

次はIIJの山本さんのセッションです。

これまでも毎年Updateされてきているzkp playgroundを使って動きを見ながらこれまでの研究成果を発表してくれています。

参考）

https://playground.zkp-ld.org

今回はこれまでBBS+で実装してきたSelective Disclosureに加えてzk-SNARKを使ったPredicateへの対応です。

具体的に言うと、単純に名前や生年月日を開示する・しないを選択できる選択的開示に加えて、21歳以上かどうか？などと言った判定結果のみを開示する、ということにも対応した、という話です。

具体的には、RDFのブランクを示す、”_;"から始まる文字列で対象となる値を置き換えます。

例）birthDate: "_:HIDDEN_DATETIME"

この状態でpredicateタイプとしてprivate<publicといった演算子を選択し、

• privateに先ほど指定した_:HIDDEN_DATETIMEを、
• publicに比較対象となる日付、例えば"2003-04-018T23:59:59Z"を

設定します。

こうすると実際の値が隠されたプロパティがpublicに指定した値よりも大きいのか小さいのか、ということがクレデンシャル内にセットされるためVerifierは判別ができる、という仕掛けです。

また、この結果のVerifiable Presentationを検証できるChrome Extensionを用意しており、例えばデモで見せてくれたのはBlueSkyに当該のVPを配置したストレージ（デモではgithub）のURLを投稿、このリンクの値を検証することで本当にこのアカウントの持ち主は21歳以上なのかどうかを検証ができる、というシナリオでした。

こう言う形で動いているものを見ながら議論ができると盛り上がっていいですね。

Learning Record - Mehesh Balan

最後はMeheshさんの学修歴クレデンシャルです。アリゾナ州立大学の学位などをVCとして発行する、というシナリオで実装をしているそうですが、実際の社会実装として適用していくためにはどうしていくのがいいのか？というどこかで聞いたような話でお悩み相談でした。

（スピーカーと私を含めて全部で3人のセッションだったので本当にお悩み相談っぽかったです）

ちょうどアリゾナ州にはTSMCの工場ができていたり、と半導体が盛り上がっているので学生を送り込みたいところなのですが、効率的にスキル証明をすることができれば、という話です。これもどこかで聞いた話だなぁ、と。

具体的なお悩みポイントは、

• Issuerのトラストをどのようにして検証するのか
• どうやってVerifier（例えばTSMC）に受け入れてもらうか

です。

まず、トラストの話はX.509のルートを辿っていく、という話も出てきましたが、技術以外にトラストフレームワークをどう捉えるのかも総合して考えないとダメだよね、という話をしました。米国の大学ではinCommonがあるのでそのSPとしてTSMCを構成すればそもそもVCじゃなくてもいいのでは？という話もありますが、卒業生や他の大学の学生などトラストフレームワークの外のエンティティをどうやって担保するのか？という話なども議論の種でした。

Verifierとの調整の話は典型的な卵・鶏の話なので、まずはアカデミアの世界でちゃんとグローバル標準を作って、より多くの大学が同じタイプのクレデンシャルを発行できる状態を作って数で勝負していなかないとダメ、という話をしました。この辺りは某QRコード決済を普及された事業者がやっていたような力技もどこかで必要になるでしょうし、政府のサポートも重要なファクターとなると思われます。

また半年後、もしくは1年後に彼とは情報交換をして進捗を確認し合っていけると良いと思いました。

ということで3日間のIIWはおしまいです。

ここに書いた話以外にもサイドで個別に議論をできたことも多く、結果的に実りのある3日間でした。また次回の秋もしくは1年後に参加して進捗を見ていきたいと思います。