Digital Credential Consortiumが公開しているVerifiable Credentials関連サービスを試す

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

Digital Credential Consortiumが公開しているOSSのVerifiable CredentialsのIssuer/Walletを試してみました。

Adminダッシュボード

https://github.com/digitalcredentials/dcc-admin-dashboard

Learner Wallet

https://lcw.app/

何をするツールなのか、というと学修歴（に限りませんが）をVerifiable Credentialとして発行する管理ツール（ダッシュボード）とそれを受け取るための学習者向けのWalletの組み合わせになっており、管理者が定義したVCを学習者に対して発行することができます。

導入方法は非常に簡単で、

https://github.com/digitalcredentials/dcc-admin-dashboard/blob/main/docs/GETTING_STARTED.md

に書かれている通り、dockerイメージを落としてきて実行するだけです。

ただ、本ツールは基本的にメールでクレデンシャル発行要求を飛ばすところから始まる前提となっているので（要所要所にOpenBadge系の匂いがします）、メールサーバの設定をしてあげる必要があります。

そのためには、手順にある

curl https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml | docker compose -f - up

ではなく、 

https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml

をダウンロードしてきてメールサーバに関する記述を変更した上で、docker-compose.ymlにリネーム、docker-compose -up -dをする方がベターです。

変更対象は

      - SMTP_HOST=sandbox.smtp.mailtrap.io

      - SMTP_USER=myusername

      - SMTP_PASS=mypassword

の３行です。私はテスト用にmailtrapを使ったので必要なSMTPホストやユーザID、パスワードはmailtrapのサンドボックスの値を使いました。

これでdockerイメージから起動すると、http://localhost:3000で管理画面へアクセスできます。初回は管理ユーザを作成するところから始まります。

最初の画面です。

まだ何もありません。

使い方としては、まず最初にCredential Templatesから発行するVCの定義を行います。

タイトルやテンプレートとなるJSONを記載してきます。

ちなみに

https://github.com/digitalcredentials/dcc-admin-dashboard/blob/main/docs/GETTING_STARTED.md

にサンプルのJSONテンプレートがあるのでそのまま使いました。

定義ができました。

次がEmail Templatesです。先ほど書いた通り、メールでVC発行をユーザへ通知する仕組みなのでそのメールの本文を定義します。

これも先ほどのドキュメントにテンプレートのサンプルがあるので、そのまま設定します。

これで設定はおしまいです。

非常に簡単です。

あとは、実際にVCを発行することになりますが、最初のIssuance OverviewのページからUpload and Prepare BatchをクリックしてVCの発行を行います。

基本は先ほどのCredential Templatesの定義とEmail Templatesの定義を指定し、CSVファイルに記載した宛先に対してメールを飛ばす仕組みになっています。

必要なフィールドを入れたCSVファイルを用意してアップロードします。

準備ができるとこんな感じで送信確認を行います。

実際に送信するとメールが届くのでメールのリンクをクリックします。

先述の通りmailtrapを使っているのでサンドボックスからメールの確認ができます。

このリンクを実行するとVC発行のQRコードが出てきます。

これを先ほどのLearner Walletで読み込みます。

すると、、、、エラーがでます。

作者のDmitriに聞いてみましたが、どうやらバグっぽいので治るのを待ちましょう。
しばらくしたらまた試してみたいと思います。

しかし、こう言うツールがOSSで出てくるのは非常にいいですね。うまくコントリビューションしていければと思います。

自民党web3PTの2024年版ホワイトペーパーのテーマの一つはDID/VC

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

先日リリースされた自民党のweb3PT（プロジェクトチーム）のホワイトペーパーのテーマの一つとしてDID/VCが取り上げられていますね。ブロックチェーン、DAO一筋だったころに比べると社会実装に向けて現実的な路線も取り入れられてきていて成熟してきた感があります。

新たなテクノロジーが社会基盤となる時代へweb3PTが「ホワイトペーパー2024」を策定

https://www.jimin.jp/news/information/208018.html

発行されたホワイトペーパーの要旨にはこんな感じで「VC及びDIDの利活用促進、DIWに関する検討」がテーマとして記載されています。実はこのDID→VCではなく「VC及びDID」となっているところが個人的には注目です。これまでのweb3ではDIDが全面に出てきていましたが、ようやく本質はVCだということが理解されてきたようです。事務局のみなさん本当にお疲れ様です。

ちなみに、平井卓也さんのInstagramに会合の様子が掲載されています。この会は私もお邪魔してVCとブロックチェーンの関係性の話を少しお話してきました。（あんなに細かい話をして良かったのかどうかは置いておいて）

ちなみにホワイトペーパーは平将明さんのページにダウンロードリンクが紹介されています。

https://www.taira-m.jp/2024/04/web3-3.html

Interopカンファレンスは今年もトラストで！

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

昨年はパネリストでおよびいただいておりましたが、今年はプログラム委員を拝命いたしましたInteropカンファレンスがいよいよ6月に迫ってきています。申し込みも開始されたようなのでぜひお越しください。

https://f2ff.jp/conf/2024/06

さて、私の担当プログラムは例によってトラストが中心です。

1. Trusted Web(1)　デジタル空間におけるトラストをいかにして実現するか？
• こちらはクロサカさん、鈴木先生と一緒にTrusted Webの進捗を語りたいと思います。ちょうどホワイトペーパーもv3.0が昨年度発行され、いろいろな取り組みが表に出てき始めていますが、まだEUのように社会実装にまでは至ってはいません。この辺りについての観測と今後の展望についてお話しできるといいのではないかと思います。
• https://f2ff.jp/introduction/8830?event_id=conf-2024-06
2. Trusted Web(2) 実社会での本格利用に向けて動き始めた分散型IDとデジタルIDウォレット
• こちらはDataSignの太田さん、DNPの岡本さん、高市さんをお招きして実際に開発をされている方々のご意見を伺ってみたいと思います。両社ともTrusted Webの実証事業者としてウォレットや分散型IDに関する基盤開発に関わってきていらっしゃる事業者の方なので、開発の実際や今後の展開における課題などを聞いていきたいと思います。
• https://f2ff.jp/introduction/8831?event_id=conf-2024-06

もちろん、これ以外にも数多くの興味深いセッションがありますので、ぜひ参加登録をしてください。

OpenID Technight #21を開催します。今回はShared SignalとIIWの振り返りです

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

半年ぶりくらいになるでしょうか？OpenID Technight #21を開催します。

今回は対面＋オンラインのハイブリッド開催です。

気になるテーマはマニアックに「Shared Signal Framework」です。まさにID基盤を裏から支える縁の下の力持ちのフレームワークで、主にリスクイベントやアイデンティティ・ライフサイクル上で発生する様々なイベントを裏側でIdP同士やIdPからクライアントへ伝達するためのシグナリングのための仕組みです。

また、時期的にもInternet Identity Workshop（IIW）の前後でありましたOpenID Foundation Workshopを含むIIWでの最新情報などについても、OpenIDファウンデーションジャパンの最新動向と合わせてお話できると思います。

ということでぜひ重し込みください。

• 日時：2024年5月16日（木）18:30〜（開場18:00）
• 場所：大手町KDDIホール＋オンライン（Youtube Live）
• 申し込みサイト：
• https://openid.connpass.com/event/316748/

お会いできるのを楽しみにしています。

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年後に参加して進捗を見ていきたいと思います。

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

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

昨日に引き続きIIW（Internet Identity Workshop）の記録です。

今日も主要なセッションについてメモしていきたいと思います。

印象に残ったのが以下のセッションです。

• Cross Platform Demo of Digital Credential API - Eric@Apple, etc.
• OpenID for VP + OpenID for VP over Browser API - Kristina, Joseph, Torsten
• Demo hour（ブータン、台湾の展示）

早速みていきます。

まずはApple/Googleからの発表です。

Cross Platform Demo of Digital Credential API - Eric@Apple, etc.

要するに、Credential APIを使ってWalletとの間のインタラクションを簡素化しましょう、という話です。

従来だとIssuance requestやPresentation requestをCross deviceだとQRコード、Same deviceだとカスタムURLスキームで、という形でブラウザとWalletとの間でやり取りをしていましたが、これまでにも触れたカスタムURLスキームの後勝ち問題など、OSの仕組み上どうしようもない課題が存在していていました。

しかし、よく考えてみると同一デバイスならブラウザから直接呼び出し、別デバイスならQRコードを表示する、というUXは他でもみたことがありますよね？そう、パスキーです。パスキーでは以前解説したとおりcredential.get()などのブラウザAPIを使って認証機能を呼び出していました。

このアイデアはOpenID for Verifiable Credentials関連の仕様においても同じ仕組みを使えるようにブラウザAPIの拡張を行うことはできないか？という話で、今回AppleとGoogleがそれぞれのデバイスで実装したデモを披露してくれました。

こんな感じでidentityDocumentのrequest/responseをブラウザAPIを使って実現します。

実際に動くデモがiOS/Androidの両方で披露されました。

OpenID for VP + OpenID for VP over Browser API - Kristina, Joseph, Torsten

前のセッションに引き続きプロトコルの面からの詳細解説です。

先に記載した通り、VerifierでPresentation requestを行うところでブラウザAPIを使うことで、現在VerifierがQRコードを自前で生成しているがこれをより安全に生成することはできないか？そして、Crossデバイスの際にパスキーでQRコードを出す仕組みをそのまま使うことでカスタムURLスキームを使わずに済むようにできないか？またフィッシングレジスタントという意味でもこの辺りはパスキーと同様の仕組みにするのがリーズナブルではないか？などモチベーションが紹介されました。

呼び出し方については

navigator.identity.get({

  digital: {

    prividers: [{

      protocol: "urn:openid.net:oid4vp"

      request: JSON.stringfy({

      　※ここにOID4VPリクエストを入れる

　　　※ただし、Client_id_scheme : "web-origin"を追加する

というイメージでAPIを実行するようです。

Demo Hour①（ブータンの国民ID）

少しセッションとは毛色が異なりますが、ブータンの国民ID、Walletの展示がありました。

オンボーディング時は軍の方が各家庭を回って本人確認〜登録を勧めたそうです。スマートフォンの配布もこの際に行ったそうです。

なお、インドと同様に各国民の生体情報（実際は特徴点情報）が国側に登録されているのでアクティベーションにいは生体情報を使います。

ざっくりメモです。

• インドの会社が作っている
• Hyperledger Ariesベース
• anonCredを使っている
• オンボーディングの際は軍が一人一人を訪ねて立ち上げをサポート
• スマホも配った
• ブートストラップする際は生体認証（そもそも国側に顔の情報が登録済み）
• 顔認証が通るとFundamental Credentialが落ちてくる
• それをベースに自己発行のクレデンシャの作成などもできる
• 民間で使う場合、例えば銀行口座を解説する場合などはサインアップ時にVCを提示してアカウントを作る
• アカウントが作られるとVCとしてWalletに取り込まれる
• そのVCを使ってオンラインバンクへのログインができる
• モチベーションとしては高地に住んでいる人が対面銀行に来るとなると標高差年全mの移動が必要となるのでデジタル化は必須だった
• ちなみにインドでも同じスタックを使っているので、インドでもこのWalletは使える
• 実際にオフィスの扉の開錠に使っている

Demo Hour②（台湾のデジタルIDウォレット）

ちょうどオードリー・タン大臣の退任が伝えられたばかりですが、台湾のデジタルIDウォレットの展示がありました。

2027年の向けてオープンソースで開発を進めているそうです。

また、トラストリストを持つことで安心して使えるようにしているのも特徴ですね。

キャラクターグッズ？をもらいました。

以下メモです。

• 細かいプロトコルやクレデンシャルフォーマットは動くので抽象化した実装となっている
• OSSで公開してブラッシュアップをしていくモデルだが、政府が７ミリオンドルくらいを毎年予算計上している
• モチベーションとしては地政学リスクを考えて、分権型としている（中央集権だと中国に乗っ取られたら終わる）
• トラストリストを作り、利用できる事業者やサービスを絞ることで利用者に安心を与えている
• オンボード時はtwFIDOとの連携している

こう言う形で実装を早い段階で展示して多くの人の意見をもらえるようにしていけるといいですね。

明日は最終日です。また記録していきたいと思います。

IIW #38 Day1クィックレビュー

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

ということで初日が終わったIIW（Internet Identity Workshop）ですが自分メモとして記録をしておきたいと思います。

といってもアンカンファレンスなのでゆるーく話を聞いていた部分も多く、特に印象に残っているセッションについてのみ記録しています。

いつものアジェンダ作成の会です。

今回私が参加したのは、以下のセッションです。

1. DCC Update - Dmitri Zagidulin
2. Should Proof of Humanity apply to My Personal AI? - Adrian
3. SD-JWT(SD-JWT VC & SD-JWT VDM) - Kristina Yasuda, Oliver Terbu
4. Decentralized Storage ＆ Bring your own identity - Aaron
5. OID4VCI Events - Oliver Terbu

どれも面白かったのですが、１番目のDCCの話と５番目のOID4VCI Eventsの話をメモしておきます。

DCC Update

ずっと追いかけているMITが中心に進めているDCC（Digital Credential Consortium）です。これまでもIIWやその他のミーティングで色々と情報交換はしてきたのですが、ここにきてかなりの進捗があったように感じます。

昨年３度目のPlugFestをJFFとジョイントで実施した、ということで実装が揃ってきているのが素晴らしいですね。

DCC自体もOSSでIssuerおよびWalletなどのモジュールを公開しています。

https://github.com/digitalcredentials

Issuerの管理ツールも公開されていて、dockerイメージなので割と簡単にセットアップできます。私も入れてみました。（細かいところは追々）

Walletについてもソースコードも公開されていますし、ストアに公開もされています。

（ちょっとカスタムURLスキームが独自過ぎるのが微妙ですが）

こう言うベースがあるとフィードバックのループも回ると思いますので成長できそうです。みなさんも触ってみてフィードバックしましょう。

OID4VCI Events

Oliverのセッションです。

OID4VCIでWalletに発行されたVCに関してShared Signalを使ってイベントを送信することでライフサイクル管理を厳格化しましょう、というシナリオの提案です。

ユースケースとしては

• Notify the wallet in case the credential got revoked before end of TTL window
• Notify the wallet in case a new credential type can be requested
• Notify the wallet thee data for one credential got updated and a new credential with the updated data is available

が挙げられていました。

ちょっと光ってしまっていますがこんなことを考えているそうです。

アイデアとしては結構面白かったのでうまく進むといいなぁ、と思います。

現時点での私のコメントはVC発行のときに使うアクセストークンとSSFの登録を行う際に使うアクセストークンはぜひスコープを分けてもらい、Issuanceの際に同じスクリーンで同意ができるようにできるといいと思います。発行はOAuthの世界で同意、プッシュ通知はモバイルアプリの世界で通知（まぁ、これはどっちにしろいるわけですが）という形でバラバラになるよりも、発行はOKだけど通知は嫌、みたいなシナリオにも最初の段階で対応できるようなUIが実現できる方が良いなぁ、と思いました。

ということでまた明日！