OpenID for Verifiable Credentials IssuanceのPublic Review期間が始まりました

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

先日のOpenID for Verifiable Presentationにつづき、いよいよ始まりました。ついにOpenID for Verifiable Credential Issuanceも2nd Implementer's Draftです。

https://openid.net/public-review-period-for-proposed-second-implementers-draft-of-openid-for-verifiable-credential-issuance/

こんなスケジュールです。

• Implementer's Draft public review period: Friday, December 20, 2024 to Sunday, February 2, 2025 (45 days)
• Implementer's Draft vote announcement: Monday, January 20, 2025
• Implementer's Draft early voting opens: Monday, January 27, 2025
• Implementer's Draft official voting period: Monday, February 3 to Tuesday, February 10, 2025

いよいよVerifiable Credentialも社会実装に向けてラストスパートな感じがします。EUDIWも2026年には本格化するわけですし。

DID CommのFormal Verificationとセキュリティ強化

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

クレデンシャル交換のプロトコルとして適しているのはDID CommなのかOpenID for Verifiable Credentials（OID4VC）なのか、という議論がひところ各所で聞かれましたが最近はそんな議論も落ち着いてきているのかな？と思っている今日この頃です（エコーチェンバー）。

当時、DID Commを否定的に捉える論拠の一つにFormal Verificationもすんでないじゃん、という話がありましたが、ようやく？やったみたいです。

What Did Come Out of It? Analysis and Improvements of DIDComm Messaging

https://eprint.iacr.org/2024/1361

Abstractにはこんなことが書いてあります。

Self-Sovereign Identity (SSI) empowers individuals and organizations with full control over their data. Decentralized identifiers (DIDs) are at its center, where a DID contains a collection of public keys associated with an entity, and further information to enable entities to engage via secure and private messaging across different platforms. A crucial stepping stone is DIDComm, a cryptographic communication layer that is in production with version 2. Due to its widespread and active deployment, a formal study of DIDComm is highly overdue.

We present the first formal analysis of DIDComm’s cryptography, and formalize its goal of (sender-) anonymity and authenticity. We follow a composable approach to capture its security over a generic network, formulating the goal of DIDComm as a strong ideal communication resource. We prove that the proposed encryption modes reach the expected level of privacy and authenticity, but leak beyond the leakage induced by an underlying network (captured by a parameterizable resource).

We further use our formalism to propose enhancements and prove their security: first, we present an optimized algorithm that achieves simultaneously anonymity and authenticity, conforming to the DIDComm message format, and which outperforms the current DIDComm proposal in both ciphertext size and computation time by almost a factor of 2. Second, we present a novel DIDComm mode that fulfills the notion of anonymity preservation, in that it does never leak more than the leakage induced by the network it is executed over. We finally show how to merge this new mode into our improved algorithm, obtaining an efficient all-in-one mode for full anonymity and authenticity.

自己主権型アイデンティティ（SSI）は、個人や組織が自分のデータを完全にコントロールできるようにする。分散型識別子（DID）がその中心であり、DIDには、エンティティに関連する公開鍵のコレクションと、エンティティが異なるプラットフォーム間で安全かつプライベートなメッセージングを介して関与できるようにするためのさらなる情報が含まれている。その重要な足がかりとなるのがDIDCommであり、バージョン2で製品化された暗号通信レイヤーである。DIDCommは広く活発に展開されているため、DIDCommの正式な研究は非常に遅れている。

本稿では、DIDCommの暗号技術に関する初の形式的分析を行い、（送信者の）匿名性と真正性というDIDCommの目標を形式化する。DIDCommの目標を強力な理想的通信リソースとして定式化することで、一般的なネットワーク上での安全性を実現する。提案する暗号化モードは、期待されるプライバシーと真正性のレベルに達するが、（パラメータ化可能なリソースによって捕捉される）基礎となるネットワークによって誘発される漏洩を超えて漏洩することを証明する。

次に、匿名性と真正性を同時に達成し、DIDCommメッセージフォーマットに適合し、暗号文のサイズと計算時間の両方において、現在のDIDCommの提案をほぼ2倍上回る最適化アルゴリズムを提示する。最後に、この新しいモードを改良されたアルゴリズムにマージする方法を示し、完全な匿名性と真正性を実現する効率的なオールインワンモードを得る。

中身はまだ細かく見ていませんが、しっかりと分析を行うプロセスが実行された、ということなので良かったんじゃないかと思います。

いずれにしても特にIoTのユースケースなどDID Commの方が適しているものもある気がしますので、ちゃんと適切にプロトコルを選択していけると良いかと思います。

GAIN Pocの第2シーズンはOpenID for Verifiable Credential Issuanceにフォーカスされます

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

OpenID Foundationや関係団体（Cloud Signature Consortium、GLEIF、IIF、OIX、その他関係する機関や個人）はグローバルで相互運用可能なアイデンティティ保証に関するネットワークに根ざしたエコシステムの達成を目指してGAIN（Global Assured Identity Network）の名のもと活動を行ってきました。

2023年、OpenID FoundationはGAIN POC Community Groupを組成して、主にOpenID Connect for Identity AssuranceとOpenID Federationをテクノロジースタックとしてどのように適用できるかについて検討を進めてきました。

その結果がGAIN in 2023というホワイトペーパーとして発行されています。

https://openid.net/announcing-gain-in-2023-whitepaper/

もちろん先に掲げた大きな目標については一朝一夕で達成されるわけではないため、継続的な議論や技術研究が必要になるわけですが、最近OpenID Foundationから2024年の取り組みについて発表がありました。

GAIN Community Group: An Update

https://openid.net/gain-community-update/

発表によると、2024年はOpenID for Verifiable Credential Issuanceにフォーカスしており、既にMeeco、Talao、Datevのウォレットを使ってIETF SD-JWT VCを発行できることの確認ができています。

今後はOpenID for Verifiable Presentationsへの展開、Open Identity Exchangeとの協業によるOpenID Federationとの組み合わせでのIssuerの信頼性の確立に向けた取り組みが続けられるということですので引き続き要注目ですね。

複数のウォレットをiPhoneにインストールすると困る話

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

先日のMyData JapanカンファレンスではDataSignさんが提供されているOWND Walletへの入場証の発行が可能なことが現地では話題になっていました。

当日のセッションでも代表の太田さんからはオープンソースであるOWND Walletのコードを使ったVESSさんのVESS Walletも紹介され、両方のアプリをインストールした方も多いのではないでしょうか？

しかし、当日実際に両方のウォレットアプリがインストールされている状態だとうまく意図したウォレットに入場証明書が入らない、という課題が発生していました。

これはiOSを少しだけ知っている人なら推測がつくと思いますが、OWND WalletとVESS Walletが同じカスタムURLスキーム（openid-credential-offer://など）を使っていることから「後から」インストールしたアプリが優先されてしまう、というiOSの仕様によって発生します。

OWND WalletかVESS Walletか、くらいの話なら気をつければ特に問題はありませんが、今後ウォレットが乱立してきて「悪意のある」ウォレットが出てきたり、「一見ウォレットに見えない」アプリが出てきた場合に思わぬ事態を招きかねない、という問題を内包しています。

この話は以前紹介したOpenID for Verifiable Credentials関連仕様のフォーマルセキュリティ分析のレポートでも指摘された課題です。

https://idmlab.eidentity.jp/2024/01/openid-for-verifiable-credentials.html

ということで、ちょっと嫌な方法ではあるのですが、各アプリケーションがどんなカスタムURLスキームを使っているのかを調べてみます。

少し古いのとMacにアプリをインストールする必要があるので個人的にはすごく嫌だったんですが、人柱になりました。

このURLを参考にしています。

https://blog.thetheorier.com/entry/extract-url-scheme

https://www.imobie.jp/iphone-tips/extract-ipa-files-from-iphone.htm

ざっくりいうと、

• ipaファイルからURLスキームを抜き出すデスクトップアプリ（実態はPythonスクリプトらしい）
• AnyTrans（商用アプリ。トライアルで試しました）

をMacに入れてあげる必要があります。（さらにいうと自分のAppleアカウントでAnyTransにサインインする必要もあるのでもっと嫌です・・・）

まずはAnyTransで対象としたいアプリをダウンロードしてMacに転送します。個人的にカスタムURLスキームが被っているのを知っているのは先に触れたOWND Wallet / VESS Wallet、あとはxIDアプリとMicrosoft Authenticatorです。

こんな感じでipaファイルが抽出されてきますので、extract_url_schemeを実行していきます。

こんな感じで各アプリがどんなURLスキームを登録しているか見えます。
この例だとMicrosoft AuthenticatorとxIDアプリがopenid-vcというURLスキームを重複登録していることがわかりますね。

これはウォレットエコシステムを作る上で大きな課題となりますので、Chrome 128ベータでも実装されてきているDigital Credential APIが本命になってくるのかと思います。

https://idmlab.eidentity.jp/2024/07/chrome-128digital-credentials-api.html

引き続き要ウォッチですね！

OpenID for Verifiable Credential IssuanceのImplementers Draftに向けた準備

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

OpenID for Verifiable Credential IssuanceもImplementer’s Draftに向けたPublic Review期間に入りました、ということを以前のポストで少しだけ触れましたが、更新履歴を見ていきたいと思います。

こちらがOpenID Foundationからの公式アナウンスです。

https://openid.net/review-of-proposed-implementers-draft-of-openid-for-verifiable-credential-issuance/

これを見ると、以下のスケジュールで進むようです。

• 2/8-3/24 Public Review期間
• 3/11 投票のアナウンス
• 3/18 早期投票開始
• 3/25-4/1 公式投票期間

問題なく進めば4月には正式にImplementer’s Draft 1が出そうですね。

Implementers Draft 1に向けて仕様がどのように更新されたのかを見るにはDocument History（Appendix F）を見るのが一番なのでこちらを見ていきましょう。

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#appendix-F

余談ですが、仕様を読む時、Appendixに結構有用な情報（議論されてきた経緯やサンプルなど）があるので是非Appendixも読むと良いと思います。

で、こちらがDocument Historyのうち、今回の更新分です。

さすが、結構多いです。（マーカーを引いた部分が個人的には結構重要な変更だと思うので既存の実装を持っている人は気をつけないと行けなさそうです。主にパラメータ名の変更などです）

• change the structure of proof_types from an array to a proof_types_supported map that contains a required proof_signing_alg_values_supported parameter
• renamed cryptographic_suites_supported to credential_signing_alg_values_supported to clarify the purpose of the parameter
• renamed credential_configurations Credential Offer parameter to credential_configuration_ids
• remove format from the Credential Response
• added signed_metadata parameter
• clarified that logo can is a uri and not a url only
• moved the annex with Credential format profiles to the top of all annexes
• added a Notification Endpoint used by the Wallet to notify the Credential Issuer of certain events for issued Credentials
• completed IANA registrations section
• clarified description of a mandatory claim
• made sure to use gender-neutral language throughout the specification
• added an option in authorization_details to use credential_configuration_id pointing to the name of a credential_configurations_supported object in the Credential Issuer's Metadata; in addition to an option to use format and type.
• renamed credentials Credential Offer parameter to credential_configuration_ids
• renamed credentials_supported Credential Issuer metadata parameter to credential_configurations_supported
• grouped credential_encryption_jwk, credential_response_encryption_alg and credential_response_encryption_enc from Credential Request into a single credential_response_encryption object
• replaced user_pin_required in Credential Offer with a tx_code object that also now contains description and length
• reworked flow description in Overview section
• removed Credential Offer examples from Credential format profiles
• added support for HTTP Accept-Language Header in the request for Credential Issuer Metadata to request a subset for display data
• clarified how the Credential Issuer indicates that it requires proof of possession of the cryptographic key material in the Credential Request
• added an option to use data integrity proofs as proof of possession of the cryptographic key material in the Credential Request
• added privacy considerations
• clarifed that AS that only supports pre-auth grant can omit response_types_supported metadata
• added background_image credential issuer metadata
• editorial clean-up (fix capitalization, etc.)

そろそろちゃんと実装初めていっても良さそうな時期にきましたね。

Walletアプリを同一端末にインストールする際の注意点

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

先日のOpenID for Verifiable Credentials関連仕様に関するセキュリティ分析の中でも触れましたが、Issuer/Holder/Verifierの３パーティモデルにではどうしてもクロスデバイス（Issuer/VerifierはPCブラウザ、Holderはスマホアプリ）のユースケースや、同一デバイス（スマホ）においてもブラウザとアプリを切り替えて利用するユースケースを想定せざるを得ません。

参考）

• OpenID for Verifiable Credentialsの正式セキュリティ分析が完了
• 引き続きOpenID for Verifiable Credentialsの正式セキュリティ分析

そのためにはWalletアプリがIssuance/Presentationに利用するカスタムURLスキームを定義する必要がありますが、例えばiOSの場合は最後にインストールしたアプリが当該のスキームを占有してしまう問題があります。その中でも最大の問題は、利用者から見てどのアプリがどのカスタムURLスキームを利用しているのかを判別することが難しい点にあります。

具体的に何が起きるか、というと利用者が無意識にインストールするアプリケーションがOpenID for Verifiable Credentialsで利用するカスタムURLスキームを利用していた場合、利用者は正しいVerifiable Credentialsを保有していたとしてもそれをうまく利用できなくなってしまいます。こうなるとIssuerやVerifierのサービスを提供している事業者からすると、利用者から問い合わせがあったとしても何が起きているのかわからず、単にうまくWalletが起動しない、という状況に見えてしまうわけです。

こんな感じになってしまします。（iOSの場合）

• クロスデバイスのケース（カメラでQRコードを読み込む場合）
• 基本的に後からインストールしたアプリが起動してしまいます。
• 後からインストールしたアプリの実装によってはカメラアプリからの起動に失敗して何も起きない、という見え方をするケースもあります。
• 同一デバイスのケース（スマホブラウザからWalletアプリを起動する場合）
• 後からインストールしたアプリを起動しようとしてしまいます。
• こんな感じです。（本来はMicrosoft Authenticatorを立ち上げようとしているのですが、別アプリが立ちあがろうとしてしまっています）

• 本来はこのようにAuthenticatorが起動します。

この状態を解消するには後からインストールしたアプリを削除するしかないので、もし後からインストールしたアプリも利用したい場合やすでに後からインストールしたアプリにもVCを発行してしまった場合などは諸々やり直しが起きてしまいます。

仕組み上どうしようもありませんが、なんとかなりませんかね。。。Appleさん。