Skip to content

OpenID for Verifiable Presentations 1.0

  • Workgroup: OpenID Digital Credentials Protocols
  • Published: 9 July 2025
  • Status: Final
  • Authors:
    • O. Terbu (MATTR)
    • T. Lodderstedt (SPRIND)
    • K. Yasuda (SPRIND)
    • D. Fett (Authlete)
    • J. Heenan (Authlete)

Abstract

本仕様は、Credentials の要求および提示のためのプロトコルを定義する。

Table of Contents

1. Introduction

本仕様は、OAuth 2.0 [RFC6749] の上に構築する仕組みとして、Credentials の Presentations を要求し、受け渡すためのメカニズムを定義する。Credentials と Presentations は任意の形式を取り得る。たとえば（これらに限定されないが）、W3C Verifiable Credentials Data Model [VC_DATA]、ISO mdoc [ISO.18013-5]、IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc] が含まれる。

OAuth 2.0 [RFC6749] は基盤プロトコルとして用いられる。これは、簡潔で安全で開発者に扱いやすい Credential 提示レイヤを、その上に構築するために必要な枠組みを提供するためである。さらに実装者は、単一のインターフェースで、Credential の提示と、Wallet 内の Credentials に基づく API アクセスのための Access Token の発行を同時にサポートできる。OpenID Connect [OpenID.Core] のデプロイメントも、本仕様を用いて実装を拡張し、Credential Presentations を運搬できるようにできる。

実装者が Self-Issued ID Tokens [SIOPv2] の発行など OpenID Connect の機能を必要とする場合、本仕様は [SIOPv2] と組み合わせて利用できる。

加えて、本仕様は Digital Credentials API (DC API) [W3C.Digital_Credentials_API] と併用して OpenID4VP を利用する方法を定義する。DC API 上での OpenID4VP の実装者に適用される要件は Appendix A を参照。明示的に本仕様の他セクションを参照している場合を除き、そのセクションは自己完結であり、当該実装者は本仕様の残りを無視できる。

1.1. Additional Authors

  • Tobias Looker (MATTR)
  • Adam Lemmon (MATTR)

1.2. Errata revisions

エラッタ更新を取り込んだ本仕様の最新改訂版は openid-4-verifiable-presentations-1_0 に公開される。承認済みの最終仕様の本文は常に openid-4-verifiable-presentations-1_0-final で参照できる。他文書から本仕様を参照する場合、openid-4-verifiable-presentations-1_0 を参照することが推奨される。

1.3. Requirements Notation and Conventions

本文書中のキーワード “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, “OPTIONAL” は、ここに示すとおりすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記載のとおり解釈される。

2. Terminology

本仕様は、OAuth 2.0 [RFC6749] で定義される “Access Token”, “Authorization Request”, “Authorization Response”, “Client”, “Client Authentication”, “Client Identifier”, “Grant Type”, “Response Type”, “Token Request”, “Token Response” を用いる。また、OpenID Connect Core [OpenID.Core] で定義される “End-User” と “Entity”、[RFC9101] で定義される “Request Object” と “Request URI”、JSON Web Token (JWT) [RFC7519] で定義される “JSON Web Token (JWT)”、JSON Web Signature (JWS) [RFC7515] で定義される “JOSE Header”、[RFC7516] で定義される “JSON Web Encryption (JWE)”、OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses] で定義される “Response Mode” を用いる。

Base64url-encoded は、[RFC7515] Section 2 で定義される、パディング無しの URL セーフ base64 エンコーディングを指す。

本仕様はさらに以下の用語を定義する。定義が異なる場合、以下の定義が優先される。

Biometrics-based Holder Binding

Holder が、指紋や顔など特定の生体的特徴を示すことで、Credential の正当な所持を証明できる能力。生体情報に基づく Holder Binding を備えた Credential の例として、Holder の肖像を含む mobile driving license [ISO.18013-5] がある。

Claims-based Holder Binding

Holder が、たとえば別の Credential を提示するなどして、氏名や生年月日といった特定の claims を証明することで、Credential の正当な所持を証明できる能力。Claims-based Holder Binding は、特定デバイス上に保管された暗号鍵素材に依存しないため、長期的かつデバイスをまたぐ Credential の利用を可能にする。この種の Credential の例として、学位証明（diploma）が挙げられる。

Credential

Credential Issuer によって主題（subject）について作成される、1 つ以上の claims の集合。本仕様では、Credentials は通常 Verifiable Credentials（後述）である。なお本仕様における “Credential” の定義は [OpenID.Core] における定義とは異なる。

Credential Format Identifier

本仕様の文脈において特定の Credential Format を示す識別子。この識別子は、当該 Credential Format に固有のパラメータの使用を示唆する。

Credential Issuer

Credentials を発行する entity。Issuer とも呼ばれる。

Cryptographic Holder Binding

Holder が、発行時および提示時に同一の private key を制御していることを証明することで、Credential の正当な所持を証明できる能力。メカニズムは Credential Format に依存し得る。たとえば jwt_vc_json Credential Format では、Cryptographic Holder Binding を備えた Credential は、Holder が制御する private key に対応する public key、またはその public key への参照を含む。

Digital Credentials API

Digital Credentials API (DC API) は、Web Platform 上の W3C Digital Credentials API [W3C.Digital_Credentials_API] および App Platforms 上の同等のネイティブ API（例: Android の Credential Manager）を指す。

Holder

Credentials を受領し、それらを制御して、Presentations として Verifiers に提示する entity。

Holder Binding or Key Binding

Holder が Credential の正当な所持を証明する能力。

Issuer-Holder-Verifier Model

claims を交換するモデル。claims は、Verifiers に Presentations として提示する処理とは独立に、Credentials の形で発行される。発行された Credential は複数回使用され得る。

Origin

呼び出し元のウェブサイトまたはネイティブ application を示す識別子であり、web または app platform により主張される。web origin は、scheme/protocol、host、port の組み合わせであり、port は scheme のデフォルト port と一致する場合は省略される。app platform は、リンクされた web origin を用いるか、app origin 用の platform 固有 URI を用いる場合がある。例として、組織 MyExampleOrg の Verifier が https://verify.example.com で提供される場合、web origin は https://verify.example.com である（https が scheme、verify.example.com が host、port は 443 が https のデフォルトであるため明示的に含まれない）。一部 platform におけるネイティブ applications の origin も https://verify.example.com であり、他の platform では platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0 のようなものになり得る。

Presentation

特定の Verifier に提示されるデータであり、Credential から導出される。本仕様では、Presentations は通常 Holder Binding を含む Verifiable Presentations（後述）だが、Holder Binding を持たない Presentations（Section 5.3 で議論）である場合もある。

VP Token

Authorization Request への応答として返される、1 つ以上の Presentations を含む artifact。VP Tokens の構造は Section 8.1 で定義される。

Verifier

Presentations を要求し、受領し、検証する entity。Verifier は OAuth 2.0 Client の特別なケースであり、[OpenID.Core] における Relying Party (RP) と同様である。

Verifiable Credential (VC)

Issuer により署名された Credential であり、その真正性を暗号学的に検証できる。Issuer-Holder-Verifier Model で使用される任意の形式を取り得る。たとえば（これらに限定されないが）、[VC_DATA] (VCDM)、[ISO.18013-5] (mdoc)、[I-D.ietf-oauth-sd-jwt-vc] (SD-JWT VC) で定義される形式が含まれる。

Verifiable Presentation (VP)

Holder Binding の暗号学的証明を備えた Presentation。Issuer-Holder-Verifier Model で使用される任意の形式を取り得る。たとえば（これらに限定されないが）、[VC_DATA] (VCDM)、[ISO.18013-5] (mdoc)、[I-D.ietf-oauth-sd-jwt-vc] (SD-JWT VC) で定義される形式が含まれる。

Wallet

Holder が Credentials と鍵素材を受領・保存・提示・管理するために用いる entity。Wallet のデプロイモデルは単一ではない。Credentials と keys はローカルに保存/管理してもよいし、リモートのセルフホストサービス、あるいはリモートの第三者サービスを用いて保存/管理してもよい。

3. Overview

本仕様は、Credentials を要求し提示するためのメカニズムを定義する。プロトコルのベースラインは OAuth 2.0 で定義される HTTPS メッセージとリダイレクトを用いる。加えて、本仕様は、HTTPS メッセージとリダイレクトの代わりに Digital Credentials API (DC API) [W3C.Digital_Credentials_API] を介して OpenID4VP メッセージを送受信する別メカニズムを定義する。

主要な拡張として、OpenID for Verifiable Presentations は、新しい response type vp_token を導入する。これにより Verifier は Verifiable Presentations と Presentations を要求し、VP Token として指定されたコンテナで受領できる。VP Token は、同一または異なる Credential formats の 1 つ以上の Verifiable Presentations および/または Presentations を含む。したがって、OpenID4VP のやり取りの結果は Access Token ではなく、1 つ以上の Verifiable Presentations および/または Presentations となる。

本仕様は Issuer-Holder-Verifier Model で使用される任意の Credential format をサポートする。たとえば（これらに限定されないが）、[VC_DATA] (VCDM)、[ISO.18013-5] (mdoc)、[I-D.ietf-oauth-sd-jwt-vc] (SD-JWT VC) が含まれる。複数形式の Credentials を同一トランザクションで提示できる。本仕様本文の例は W3C Verifiable Credentials を用いるが、他の Credential formats の例は Appendix B に示す。

OpenID for Verifiable Presentations は、Verifier が End-User とやり取りするデバイスが、要求対象 Credential(s) が保存されているデバイスと同一の場合も異なる場合も、いずれもサポートする。

本仕様は、リダイレクトによる応答送信に加え、HTTP POST request による送信もサポートする。これにより、デバイス間で応答を送れたり、リダイレクト URL の文字数制限を応答サイズが超える場合にも送れたりする。

要約すると、OpenID for Verifiable Presentations は、相互運用性を実現するために profiling を必要とするフレームワークである。profiling とは以下を定義することを意味する。

  • どの optional features を使用するか、または実装必須とするか（例: 応答の暗号化）
  • パラメータに許容される値（例: Credential Format Identifiers）
  • optional に、新機能のための拡張

3.1. Same Device Flow

Figure 1 は、End-User が、Wallet が存在するのと同じデバイス上で End-User とやり取りしている Verifier に Credential を提示するフローの図である。

このフローは、Verifier と Wallet 間で Authorization Request と Authorization Response を受け渡すために、単純なリダイレクトを利用する。Response Mode が fragment の場合、Presentations は redirect_uri の fragment 部分として Verifier に返される。

注: 図は本仕様の optional features をすべて示してはいない。

+--------------+   +--------------+                                    +--------------+
|   End-User   |   |   Verifier   |                                    |    Wallet    |
+--------------+   +--------------+                                    +--------------+
        |                 |                                                   |
        |    Interacts    |                                                   |
        |---------------->|                                                   |
        |                 |  (1) Authorization Request                        |
        |                 |  (DCQL query)                                     |
        |                 |-------------------------------------------------->|
        |                 |                                                   |
        |                 |                                                   |
        |   End-User Authentication / Consent                                 |
        |                 |                                                   |
        |                 |  (2)   Authorization Response                     |
        |                 |  (VP Token with Presentation(s))                  |
        |                 |<--------------------------------------------------|
Figure 1: Same Device Flow

(1) Verifier は Authorization Request を Wallet に送信する。これには、Verifier が提示を要求する Credential(s) の要件を記述する Digital Credentials Query Language (DCQL)（Section 6 参照）の query が含まれる。要件には、どの種別の Credential(s) を、どの format(s) で、Credential(s) 内のどの individual Claims を（Selective Disclosure）、などが含まれ得る。Wallet は Authorization Request を処理し、Verifier の要求に合致する利用可能な Credentials を判定する。Wallet は End-User を認証し、要求された Credentials を提示するための同意を収集する。

(2) Wallet は、End-User が提示に同意した Credential(s) の Presentation(s) を準備する。次に Wallet は、Presentation(s) が vp_token パラメータに含まれる Authorization Response を Verifier に送信する。

3.2. Cross Device Flow

Figure 2 は、End-User が、Wallet が存在するデバイスとは異なるデバイスで End-User とやり取りしている Verifier に Credential を提示するフローの図である。

このフローでは、Verifier が Authorization Request を準備して QR Code として表示する。End-User は Wallet を用いて QR Code をスキャンする。Presentations は、Verifier が制御する URL への直接の HTTP POST request により Verifier に送信される。このフローは、本仕様で定義される Response Type vp_token と Response Mode direct_post を組み合わせて用いる。QR Code のサイズを小さくし、Request Object への署名と optional な暗号化を可能にするため、実際の Authorization Request には Client Identifier と Request URI（[RFC9101] により要求）だけを含め、Wallet は Request URI を用いて実際の Authorization Request データを取得する。

注: 図はすべてのパラメータや optional features を示していない。

注: [RFC9101] で定義される Request URI の利用は、プロトコル拡張点における他の選択に依存しない。すなわち Same Device Flow でも利用できる。

+--------------+   +--------------+                                    +--------------+
|   End-User   |   |   Verifier   |                                    |    Wallet    |
|              |   |  (device A)  |                                    |  (device B)  |
+--------------+   +--------------+                                    +--------------+
        |                 |                                                   |
        |    Interacts    |                                                   |
        |---------------->|                                                   |
        |                 |  (1) Authorization Request                        |
        |                 |      (Request URI)                                |
        |                 |-------------------------------------------------->|
        |                 |                                                   |
        |                 |  (2) Request the Request Object                   |
        |                 |<--------------------------------------------------|
        |                 |                                                   |
        |                 |  (2.5) Respond with the Request Object            |
        |                 |      (DCQL query)                                 |
        |                 |-------------------------------------------------->|
        |                 |                                                   |
        |   End-User Authentication / Consent                                 |
        |                 |                                                   |
        |                 |  (3)   Authorization Response as HTTP POST        |
        |                 |  (VP Token with Presentation(s))                  |
        |                 |<--------------------------------------------------|
Figure 2: Cross Device Flow

(1) Verifier は Wallet に対し、Authorization Request parameters を含む Request Object を取得するための Request URI を含んだ Authorization Request を送信する。

(2) Wallet は Request URI に対して HTTP GET request を送信し、Request Object を取得する。

(2.5) HTTP GET response は Authorization Request parameters を含む Request Object を返す。これには、Verifier が提示を要求する Credential(s) の要件を記述する DCQL query が含まれる。要件には、どの種別の Credential(s) を、どの format(s) で、Credential(s) 内のどの individual Claims を（Selective Disclosure）、などが含まれ得る。Wallet は Request Object を処理し、Verifier の要求に合致する利用可能な Credentials を判定する。Wallet は End-User を認証し、要求された Credentials を提示するための同意を収集する。

(3) Wallet は、End-User が提示に同意した Credential(s) の Presentation(s) を準備する。次に Wallet は、Presentation(s) が vp_token パラメータに含まれる Authorization Response を Verifier に送信する。

4. Scope

OpenID for Verifiable Presentations は、既存の OAuth 2.0 メカニズムを以下のように拡張する。

  • 新しい query language として Digital Credentials Query Language (DCQL) を定義し、Presentations の要求をより容易かつ柔軟にする。詳細は Section 6。
  • 新しい dcql_query Authorization Request parameter を定義し、JSON でエンコードされた DCQL 形式で Credentials の Presentation を要求できるようにする。詳細は Section 5。
  • 新しい vp_token response parameter を定義し、Holder Binding の有無にかかわらず Presentations を Verifier に返せるようにする（Response Type に応じて Authorization Response または Token Response）。詳細は Section 8。
  • 新しい Response Types vp_token および vp_token id_token を定義し、Authorization Response で Credentials を返すことを要求できるようにする（単独、または Self-Issued ID Token [SIOPv2] と併せて）。詳細は Section 8。
  • 新しい OAuth 2.0 Response Mode direct_post を定義し、デバイス間で応答を送ることや、応答サイズがリダイレクト URL の文字数制限を超える場合をサポートする。詳細は Section 8.2。
  • format parameter をプロトコル全体で用い、特定の Credential format のニーズに合わせたカスタマイズを可能にする。Appendix B の例は [VC_DATA], [ISO.18013-5], [I-D.ietf-oauth-sd-jwt-vc] の Credential formats を想定する。
  • Client Identifier Prefix の概念を導入し、[RFC6749] の範囲を超えて Verifier metadata の取得・検証メカニズムを使い分けられるようにする。
  • Digital Credentials API を用いた OpenID4VP の利用を規定するメカニズム（Appendix A 参照）。
  • OpenID for Verifiable Presentations による Credentials の提示は、[SIOPv2] による End-User 認証と組み合わせたり、OAuth 2.0 Access Tokens の発行と組み合わせたりできる。

5. Authorization Request

Authorization Request は [RFC6749] の定義に従い、適用可能な場合は [RFC9700] の推奨も考慮する。

Verifier は、JWT-Secured Authorization Request (JAR) [RFC9101] で定義されるとおり、Authorization Request を Request Object として値渡しまたは参照渡しで送信してよい。Verifiers は Request Objects に typ Header Parameter を含め、その値を [RFC9101] で定義される oauth-authz-req+jwt としなければならない。Wallets は、typ Header Parameter が存在しない、または値が oauth-authz-req+jwt ではない Request Objects を処理してはならない。

client_id claim は後述のとおり必須であり、JAR で一般的に用いられる Request Object 内の iss claim と重複する。既存の JAR 実装を壊さないため、iss claim は Request Object に存在してよい。ただし存在する場合、Wallet はそれを無視しなければならない。

本仕様は、Wallet が Verifier に対し、Wallet の技術的能力の詳細を提供し、Verifier がその Wallet の能力に合致する request を生成できるようにするための新しいメカニズムを定義する。これを可能にするため、Authorization Request は request_uri_method parameter に post を指定できる。これは、Wallet が Verifier の request_uri endpoint に対して、Section 5.10 で定義されるとおり、その能力情報を含む HTTP POST request を行えることを Wallet に通知する。Wallet は、request_uri_method=post を受け取っても当該機能をサポートしない場合、引き続き JAR に従って処理してよい。

Verifier は dcql_query parameter を用いて、要求する Credential(s) の要件を表現する。Wallet 実装は DCQL query を処理し、Section 6.4 で記述される評価手順に従って候補 Credential(s) を選択しなければならない。

Verifier は client_id parameter の prefix として Client Identifier Prefix を伝達し、Wallet が Client identification / authentication / authorization の過程において Client Identifier と関連データをどのように解釈すべきかを示す。これにより、本仕様のデプロイメントは、[RFC6749] の範囲を超えた多様な Client metadata の取得・検証メカニズムを利用できる。ある Client Identifier Prefix は、Verifier が認証手段として Authorization Request に署名する必要があるか、追加パラメータを渡す必要があるか、さらに Wallet にそれらを処理させる必要があるか、といった要件を定める。

Client Identifier Prefix に応じて、Verifier は client_metadata parameter を用いて、name/value ペアを含む Verifier metadata の JSON object を伝達できる。

本セクションで定義される以外の追加 request parameters も、[RFC6749] に記述されるとおり、定義して利用してよい。Wallet は、transaction_data parameter を除き、認識できない parameters を無視しなければならない。この規則の例外が transaction_data である。この parameter をサポートしない Wallet は、それを含む request を拒否しなければならない。

5.1. New Parameters

本仕様は以下の新しい request parameters を定義する。

dcql_query

Section 6 で定義される DCQL query を含む JSON object。

Authorization Request には、dcql_query または DCQL Query を表す scope parameter のいずれか一方が存在しなければならないが、両方が存在してはならない。

[RFC6749] に基づく authorization request の文脈では、object を含む parameters は、request parameters として通常どおり application/x-www-form-urlencoded 形式で、JSON シリアライズされた文字列として転送される。

client_metadata

OPTIONAL。Verifier metadata values を含む JSON object。UTF-8 でエンコードされなければならない。以下の metadata parameters を使用してよい。

  • jwks: OPTIONAL。[RFC7591] で定義される JSON Web Key Set。1 つ以上の public keys を含む。たとえば、Wallet が鍵合意の入力として用いる鍵（Authorization Response の暗号化に利用され得る。Section 8.3 参照）や、Wallet が Verifiable Presentation を生成するために Verifier の public key を必要とする場合に用いる鍵など。これにより Verifier は、この Authorization Request に固有の ephemeral keys を渡せる。この parameter に含まれる public keys は、署名された Authorization Requests の署名検証に用いてはならない。set 内の各 JWK は、request の文脈で鍵を一意に識別する kid (Key ID) parameter を持たなければならない。
  • encrypted_response_enc_values_supported: OPTIONAL。空でない string の配列。各 string は Response を暗号化する際の content encryption algorithm として用い得る JWE [RFC7516] の enc algorithm を表す。Response の暗号化を要する response_mode（例: dc_api.jwt または direct_post.jwt）が指定される場合、デフォルトの単一値 A128GCM 以外を用いるなら、これが存在しなければならない。そうでない場合、これは存在しないことが望ましい。
  • vp_formats_supported: Wallet が別メカニズムで取得できない場合は REQUIRED。Section 11.1 で定義される。

Wallet が他ソースから取得できる Client についての authoritative data（例: OpenID Federation Entity Statement によるもの）は、client_metadata で渡された値より優先される。

他の metadata parameters は、本仕様の profile がそれらを client_metadata parameter で利用可能と明示的に定義しない限り、無視しなければならない。

request_uri_method

OPTIONAL。同一 request に request_uri parameter が含まれる場合に、その取得で用いる HTTP method を決定する string。本仕様は、大小文字を区別する有効値として get と post の 2 つを定義する。request_uri_method=get の場合、Wallet は [RFC9101] で定義されるとおり HTTP GET method を用いて Request Object を取得する request を送らなければならない。request_uri_method=post の場合、これをサポートする Wallet は Section 5.10 の詳細に従い HTTP POST method を用いて request を送らなければならない。request_uri_method が存在しない場合、Wallet は [RFC9101] で定義されるとおり request_uri parameter を処理しなければならない。post method をサポートしない Wallet は、Request URI に対して GET request を送信する（[RFC9101] で定義されるデフォルト動作）。request_uri parameter が存在しない場合、request_uri_method parameter は存在してはならない。

Verifier が request_uri_method=post を設定し、かつ Wallet に能力を伝える他手段がない場合、Verifier は Authorization Request に client_metadata parameter を追加することが望ましい。これにより Wallet は Verifier の能力を評価でき、Request URI への POST request に含める wallet_metadata parameter を通じて、関連する能力のみを送信できる。

transaction_data

OPTIONAL。空でない string の配列。各 string は base64url-encoded の JSON object であり、Verifier が End-User に認可してほしいトランザクションの詳細を含む typed parameter set を格納する。詳細は Section 8.4。Wallet は、request が（たった 1 つでも）認識できない transaction data type を含む、または transaction data が該当 type 定義に適合しない場合、エラーを返さなければならない。transaction data の type により定まる parameters に加え、各 transaction_data object は本仕様で定義される以下の parameters からなる。

  • type: REQUIRED。transaction data の type を識別する string。この値が、transaction_data object に含められる parameters を決定する。具体値は本仕様のスコープ外である。type 値には衝突耐性のある名前を用いることが推奨される。
  • credential_ids: REQUIRED。空でない string の配列。各要素は、この transaction を認可するために利用できる、Verifier が要求した Credential を参照する。string は DCQL Credential Query の id field と一致する。配列に複数要素がある場合、Wallet は参照された Credentials のうち 1 つのみを transaction authorization に用いなければならない。

transaction data type の詳細を規定する各文書は、それらの transactions を認可するためにどの Credential(s) を用いられるかを定義する。それらの Credential(s) は transaction authorization のユースケース向けに特別に発行してもよいし、ユーザ識別に用いる既存の Credential(s) を再利用してもよい。ある Credential が transaction data の認可に利用可能であることを Credential Issuers が表現するメカニズムは、本仕様のスコープ外である。

以下は、transaction_data parameter の strings のうち 1 つを base64url デコードした後の、transaction data content の非規範例である。

{
  "type": "example_type",
  "credential_ids": ["id_card_credential"]
  // other transaction data type specific parameters
}

verifier_info

OPTIONAL。空でない配列であり、Credential Request に関連する Verifier に関する attestation を含む。これらの attestation は、Verifier metadata、policies、trust status、authorizations などを含み得る。attestations は、認可判断の支援、Wallet policy enforcement への情報提供、あるいは End-User の同意ダイアログの情報拡充を目的とする。各 object は以下の構造を持つ。

  • format: REQUIRED。attestation の format と、そのエンコード方法を識別する string。エコシステムは衝突耐性のある識別子を用いることが望ましい。attestation のさらなる処理は type により決まり、format 固有の方法で規定される。
  • data: REQUIRED。attestation（例: JWT）を含む object または string。payload 構造は format レベルで定義される。Wallet が verifier_info の情報を使用するかどうかは Wallet の裁量である。Wallet の判断に影響する要因には（これらに限定されないが）、Wallet がサポートする trust framework、Issuers やエコシステムによって定義される特定の policies、本仕様の profiles などがある。Wallet が verifier_info の情報を使用する場合、Wallet は署名を検証し、binding を保証しなければならない。
  • credential_ids: OPTIONAL。空でない string の配列。attestation が関連する、Verifier が要求した Credential を参照する。各 string は DCQL Credential Query の id field と一致する。省略された場合、attestation は要求されたすべての Credentials に関連する。

詳細は Section 5.11 を参照。

以下は、attested object の非規範例である。

{
  "format": "jwt",
  "data": "eyJhbGciOiJFUzI1...EF0RBtvPClL71TWHlIQ",
  "credential_ids": ["id_card"]
}

5.2. Existing Parameters

既存の Authorization Request parameters について、以下の追加考慮事項を示す。

nonce

REQUIRED。Wallet により提供される Verifiable Presentation(s) を特定の transaction に安全に紐付けるための、大小文字を区別する String。Verifier は、各 Authorization Request ごとに十分なエントロピーを持つ新鮮な暗号学的乱数を生成し、現在の session とともに保存し、nonce Authorization Request Parameter として Wallet に渡さなければならない。詳細は Section 14.1。値は ASCII URL safe characters（英大文字・英小文字・10 進数字・ハイフン・ピリオド・アンダースコア・チルダ）のみを含まなければならない。

scope

OPTIONAL。[RFC6749] で定義される。Wallet は、事前定義された scope 値を利用して、Verifier が Presentations を要求することを許可してよい。詳細は Section 5.5。

response_mode

REQUIRED。[OAuth.Responses] で定義される。この parameter は（新しい Response Mode direct_post を通じて）、Wallet が HTTPS 接続を介して Verifier に応答を送るよう求めるために用いられる（詳細は Section 8.2）。また、結果の応答を暗号化するよう求めるためにも用いられる（詳細は Section 8.3）。

client_id

REQUIRED。[RFC6749] で定義される。本仕様は、Section 5.9 で述べる Client Identifier Prefixes の利用を可能にするための追加要件を定義する。Client Identifier は Wallet 以外の当事者によって作成され得る。また Client Identifier Prefix と組み合わせて用いられる場合、Wallet の文脈で一意であると見なされる。

state

Section 5.3 で定義される条件下では REQUIRED。そうでない場合 state は OPTIONAL。state の値は ASCII URL safe characters（英大文字・英小文字・10 進数字・ハイフン・ピリオド・アンダースコア・チルダ）のみを含まなければならない。

5.3. Requesting Presentations without Holder Binding Proofs

本仕様の主要なユースケースは Verifiable Presentations、すなわち暗号学的な Holder Binding proof を含む Presentations を要求し提示することである。

しかし、Verifier が、Cryptographic Holder Binding の proof を伴わない Credentials の提示を要求したいユースケースも存在する。例として、Holder Binding をサポートしない低セキュリティの Credentials（例: 映画のチケット）、生体的特徴に紐付く Credentials、または claims に紐付く Credentials（例: 学位証明）がある。場合によっては、Credentials が Holder Binding をサポートしていても、Verifier がその Presentation に対して Holder Binding を要求しないこともある。

Verifier が Holder Binding の proof を伴わない Credential の Presentation を要求し受け入れる場合、提示された Credential がリプレイされ得ることを受け入れることになる。このケースについての追加考慮事項は Section 14.1 に含まれる。

Holder Binding の proof を伴わない Credential を要求するために、Verifier は Section 6 と Appendix B で定義される DCQL request において require_cryptographic_holder_binding parameter を用いる。

本プロトコルでは、nonce parameter は request と response を安全に関連付け、Holder Binding proof におけるリプレイ防止として機能する。Key binding proof がない場合、nonce は response で返されない。request と response の binding を維持するため、Verifier は以下をしなければならない。

  • [RFC6749] Section 4.1.1 で定義される state parameter を Authorization Request に含める
  • 値が少なくとも 128 bits のエントロピーを持つ暗号学的に強い擬似乱数であることを保証する
  • 各 Authorization Request ごとに新鮮な値を選ぶことを保証する
  • Verifier の session state に保存する
  • Authorization Response に同一の state 値が返ることを確認する

ただし、Holder Binding のない Presentation を少なくとも 1 つ要求する場合であり、かつ Digital Credentials API を用いない場合に限る。Digital Credentials API は binding を維持する内部メカニズムを用いる。

Response Mode direct_post を用いる場合、Section 14.3 も参照。

5.4. Examples

Verifier は、以下 3 つのいずれかの方法で Authorization Request を送信してよい。

  • URL に encoded parameters を渡す
  • request object を値として渡す
  • request object を参照として渡す

後者 2 つの options は、JWT-Secured Authorization Request (JAR) [RFC9101] で定義される。

以下は、URL-encoded parameters を用いた Authorization Request の非規範例である。

GET /authorize?
  response_type=vp_token
  &client_id=redirect_uri%3Ahttps%3A%2F%2Fclient.example.org%2Fcb
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &dcql_query=...
  &transaction_data=...
  &nonce=n-0S6_WzA2Mj HTTP/1.1

以下は、Request Object を値として渡す Authorization Request の非規範例である。

GET /authorize?
  client_id=redirect_uri%3Ahttps%3A%2F%2Fclient.example.org%2Fcb
  &request=eyJrd...

ここで request query parameter の内容は、（例では RS256 algorithm で）base64url-encoded され署名された Request Object である。デコードされた payload は以下である。

{
  "iss": "redirect_uri:https://client.example.org/cb",
  "aud": "https://self-issued.me/v2",
  "response_type": "vp_token",
  "client_id": "redirect_uri:https://client.example.org/cb",
  "redirect_uri": "https//client.example.org/cb",
  "dcql_query": {
    "credentials": [
      {
        "id": "some_identity_credential",
        "format": "dc+sd-jwt",
        "meta": {
          "vct_values": ["https://credentials.example.com/identity_credential"]
        },
        "claims": [
          { "path": ["last_name"] },
          { "path": ["first_name"] }
        ]
      }
    ]
  },
  "nonce": "n-0S6_WzA2Mj"
}

以下は、request object を参照として渡す Authorization Request の非規範例である。

GET /authorize?
  client_id=x509_san_dns%3Aclient.example.org
  &request_uri=https%3A%2F%2Fclient.example.org%2Frequest%2Fvapof4ql2i7m41m68uep
  &request_uri_method=post HTTP/1.1

実際の request を取得するために、Wallet は request_uri に対して以下の非規範例の HTTP request を送る場合がある。

POST /request/vapof4ql2i7m41m68uep HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded

wallet_metadata=%7B%22vp_formats_supported%22%3A%7B%22dc%2Bsd-jwt%22%3A%7B%22sd-jwt_alg
_values%22%3A%20%5B%22ES256%22%5D%2C%22kb-jwt_alg_values%22%3A%20%5B%22ES256%22%5D%7D%7
D%7D%7D&
wallet_nonce=qPmxiNFCR3QTm19POc8u

5.5. Using scope Parameter to Request Presentations

Wallets は OAuth 2.0 の scope 値を用いて Presentations を要求することをサポートしてよい。

そのような scope 値は、十分に定義された DCQL query の alias でなければならない。複数の scope 値を同時に用いることができるため、scope 値に紐付く DCQL queries 内の Credentials の identifiers（Section 6.1 参照）および claims（Section 6.3 参照）の identifiers は一意でなければならない。これにより、DCQL queries で用いられる identifiers 間の衝突が発生せず、Verifier は response 内の要求 Credentials を曖昧さなく識別できる。

特定の scope 値、およびある scope 値と対応する DCQL query の対応付けは、本仕様のスコープ外である。

考えられる options としては、scope 値を規範的に定義し、その意味論を記述する別仕様の本文、または Wallet の server metadata における機械可読定義（scope 値を等価な DCQL request に対応付ける）などがある。

衝突耐性のある scope 値を用いることが推奨される。

以下は、例の scope 値 com.example.IDCardCredential_presentation を用いた Authorization Request の非規範例である。

GET /authorize?
  response_type=vp_token
  &client_id=https%3A%2F%2Fclient.example.org%2Fcb
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &scope=com.example.healthCardCredential_presentation
  &nonce=n-0S6_WzA2Mj HTTP/1.1

5.6. Response Type vp_token

本仕様は Response Type vp_token を定義する。

vp_token

Authorization Request の response_type parameter に指定される場合、成功 response は vp_token parameter を含まなければならない。Wallet は、grant request に対する成功 response において、OAuth 2.0 Authorization Code、Access Token、または Access Token Type を返すべきではない。Response Type vp_token のデフォルト Response Mode は fragment である。すなわち、Authorization Response parameters は Verifier へリダイレクトする際に redirect_uri に追加される fragment にエンコードされる。Response Type vp_token は [OAuth.Responses] で定義される他の Response Modes とともに利用できる。成功 response と error response は、指定された Response Mode を用いて返すことが望ましい。指定がない場合は、デフォルト Response Mode を用いることが望ましい。

response_type 値が VP Token を返す response をどのように決定するかは、Section 8 を参照。

5.7. Passing Authorization Request Across Devices

要求された Credential が保存されているデバイスとは異なるデバイスで Authorization Request が表示されるユースケースがある。その場合、Authorization Request は QR Code として表示することでデバイス間で受け渡せる。

Authorization Request のサイズが大きくなり得て QR code に収まらない可能性があるため、request_uri と組み合わせて Response Mode direct_post（Section 8.2 参照）を利用することが推奨される。

5.8. aud of a Request Object

Verifier が [RFC9101] で定義される Request Object を送信する場合、aud claim の値は、Verifier が request の受信者を識別できるかどうかにより決まる。

  • Dynamic Discovery が行われる場合、aud claim は iss (issuer) claim の値と等しくなければならない。
  • Static Discovery metadata が用いられる場合、aud claim は "https://self-issued.me/v2" でなければならない。

注: "https://self-issued.me/v2" は象徴的な string であり、本仕様が SIOPv2 なしで単独利用される場合でも aud claim の値として用いられる。

5.9. Client Identifier Prefix and Verifier Metadata Management

本仕様は Client Identifier Prefix の概念を定義する。これは、Client identification / authentication / authorization の過程において、Wallet が Client Identifier と関連データをどのように解釈すべきかを規定する。Client Identifier Prefix により、本仕様のデプロイメントは、[RFC6749] の範囲を超えた Verifier metadata の取得・検証メカニズムを用いられる。Verifier は OAuth 2.0 Client として振る舞うため、この用語は Client Identifier Prefix と呼ばれる。

Client Identifier Prefix は string であり、Verifier は Authorization Request の client_id parameter 内の prefix としてそれを伝達してよい。Client Identifier Prefix が提供されなかった場合に備え、[RFC6749] における pre-registered Clients へのフォールバックはデフォルトメカニズムとして維持される。ある Client Identifier Prefix は、Verifier が認証手段として Authorization Request に署名することや、追加パラメータを渡して Wallet にそれらの処理を要求することを必要とし得る。

5.9.1. Syntax

client_id Authorization Request parameter と、Client Identifier が用いられる他の場所では、Client Identifier Prefixes は通常の Client Identifier の前に :（コロン）で区切って付与される。

  • <client_id_prefix>:<orig_client_id>

ここで <client_id_prefix> は Client Identifier Prefix、<orig_client_id> はその prefix の namespace 内での Client の識別子である。本仕様が定義する Client Identifier Prefixes は Section 5.9.3 を参照。

Wallets は、:（コロン）文字の存在と、その前の内容を用いて Client Identifier Prefix が使われているかどうかを判断しなければならない。: が存在し、その前の内容が認識でき、かつサポートする Client Identifier Prefix の値である場合、Wallet は当該 Client Identifier Prefix に従って Client Identifier を解釈しなければならない。Client Identifier Prefix は（最初の）: の前の string として定義される。実装は、: の存在が値全体を有効な URI として処理できることを意味すると仮定すべきではない。代わりに、指定された Client Identifier Prefix に対して定義された特定の処理規則（Section 5.9.3 参照）を用いて client_id 値を解析すべきである。

たとえば、Authorization Request が client_id=verifier_attestation:example-client を含む場合、verifier_attestation Client Identifier Prefix を用いるべきであり、かつこの prefix の範囲で Verifier が example-client という string で識別されることを示す。presentation は、audience（意図された受信者）として verifier_attestation:example-client の完全な string を含む。また、同じ完全な string が OAuth フロー内のどこでも Client Identifier として用いられる。

Verifier は、サポートされる prefix を選ぶために、Authorization Request を送信する前に Wallet がどの Client Identifier Prefixes をサポートしているかを判断する必要がある点に留意すること。

Client Identifier Prefix に応じて、Verifier は client_metadata parameter を用いて name/value ペアを含む Verifier metadata の JSON object を伝達できる。

5.9.2. Fallback

Client Identifier に : が存在しない場合、Wallet は Client Identifier を pre-registered client を参照するものとして扱わなければならない。これは [RFC6749] のデフォルト動作に等しい。すなわち Client Identifier は Authorization Request に先立って Wallet に既知でなければならない。Verifier metadata は [RFC7591] または out-of-band メカニズムにより取得される。

たとえば、Authorization Request が client_id=example-client を含む場合、Wallet は Client Identifier が pre-registered client を指すと解釈する。

Client Identifier に : が存在するが、その前の値が認識できるかつサポートする Client Identifier Prefix の値ではない場合、Wallet は Client Identifier を pre-registered client を参照するものとして扱ってもよいし、request を拒否してもよい。

この定義から、pre-registered clients は、Client Identifier の最初の部分に、サポートされる Client Identifier Prefix の値が直前にある : 文字を含んではならないことが導かれる。

5.9.3. Defined Client Identifier Prefixes

本仕様は以下の Client Identifier Prefixes を定義する（適用可能な場合は例も示す）。

Appendix A で定義される DC API 上の OpenID4VP を用いる場合、Wallet が、関連する Client Identifier Prefix により定義される処理規則に従って Request Object の署名を検証するかどうかは Wallet の裁量である。Wallet の判断に影響する要因には（これらに限定されないが）、Wallet がサポートする trust framework、Issuers やエコシステムによって定義される特定の policies、本仕様の profiles などがある。

redirect_uri

この prefix 値は、元の Client Identifier 部分（redirect_uri: prefix を除いた部分）が、Verifier の Redirect URI（Response Mode direct_post が用いられる場合は Response URI）であることを示す。Verifier は redirect_uri Authorization Request parameter（または Response Mode direct_post が用いられる場合は response_uri）を省略してよい。すべての Verifier metadata parameters は、Section 5.1 で定義される client_metadata parameter を用いて渡さなければならない。Client Identifier 値の例は redirect_uri:https://client.example.org/cb である。Wallet が検証用の trusted key を取得する方法がないため、redirect_uri Client Identifier Prefix を用いる requests は署名できない。したがって、署名された requests を要求する実装は redirect_uri Client Identifier Prefix を利用できない。

以下は redirect_uri Client Identifier Prefix を用いる署名なし request の非規範例である。

HTTP/1.1 302 Found
Location: https://wallet.example.org/universal-link?
  response_type=vp_token
  &client_id=redirect_uri%3Ahttps%3A%2F%2Fclient.example.org%2Fcb
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &dcql_query=...
  &nonce=n-0S6_WzA2Mj
  &client_metadata=%7B%22vp_formats_supported%22%3A%7B%22dc%2Bsd-jwt%22%3A%7B%22sd-jwt_
  alg_values%22%3A%20%5B%22ES256%22%5D%2C%22kb-jwt_alg_values%22%3A%20%5B%22ES256%22%5D
  %7D%7D%7D

openid_federation

この prefix 値は、元の Client Identifier（openid_federation: prefix を除いた部分）が OpenID Federation [OpenID.Federation] で定義される Entity Identifier であることを示す。[OpenID.Federation] で与えられる処理規則に従わなければならない。Authorization Request は trust_chain parameter を含んでもよい。最終的な Verifier metadata は、[OpenID.Federation] に従って policies を適用した後、Trust Chain から取得される。Authorization Request に client_metadata parameter が存在する場合、この Client Identifier Prefix が使用されるときは無視しなければならない。Client Identifier の例: openid_federation:https://federation-verifier.example.com。

decentralized_identifier

この prefix 値は、元の Client Identifier（decentralized_identifier: prefix を除いた部分）が [DID-Core] で定義される Decentralized Identifier であることを示す。request は DID に関連付く private key で署名されなければならない。署名を検証するための public key は、DID Document の verificationMethod property から取得しなければならない。DID Document は複数の public keys を含み得るため、対象 request の署名に用いられた特定の public key は JOSE Header の kid により識別されなければならない。DID Document を取得するため、Wallet は Verifier が用いる DID method により定義される DID Resolution を用いなければならない。public key 以外のすべての Verifier metadata は、Section 5.1 で定義される client_metadata parameter から取得しなければならない。Client Identifier の例: decentralized_identifier:did:example:123。

decentralized_identifier Client Identifier Prefix の場合における、署名された Request Object の header と body の非規範例を以下に示す。

Header

{
  "typ": "oauth-authz-req+jwt",
  "alg": "RS256",
  "kid": "did:example:123#1"
}

Body

{
  "client_id": "decentralized_identifier:did:example:123",
  "response_type": "vp_token",
  "redirect_uri": "https://client.example.org/callback",
  "nonce": "n-0S6_WzA2Mj",
  "dcql_query": { ... },
  "client_metadata": {
    "vp_formats_supported": {
      "dc+sd-jwt": {
        "sd-jwt_alg_values": ["ES256", "ES384"],
        "kb-jwt_alg_values": ["ES256", "ES384"]
      }
    }
  }
}

verifier_attestation

この Client Identifier Prefix は、Section 12 で定義される、特定の public key に bound された JWT を用いた Verifier の認証を可能にする。Client Identifier Prefix が verifier_attestation の場合、元の Client Identifier（verifier_attestation: prefix を除いた部分）は、Verifier attestation JWT の sub claim の値と等しくなければならない。request は、Verifier attestation JWT の cnf claim にある public key に対応する private key で署名されなければならない。これは当該 key の所持証明となる。Verifier attestation JWT は request object の jwt JOSE Header に追加されなければならない（Section 12 参照）。Wallet は Verifier attestation JWT の署名を検証しなければならない。Verifier Attestation JWT の iss claim の値は、Wallet が Verifier Attestation JWTs の発行者として信頼する party を識別しなければならない。Wallet が trust を確立できない場合、request を拒否しなければならない。Verifier Attestation JWT の issuer が redirect_uris claim を attestation に追加する場合、Wallet は redirect_uri request parameter の値が redirect_uris claim の entries のいずれかと完全一致することを保証しなければならない。public key 以外のすべての Verifier metadata は client_metadata parameter から取得しなければならない。Client Identifier の例: verifier_attestation:verifier.example。

x509_san_dns

Client Identifier Prefix が x509_san_dns の場合、元の Client Identifier（x509_san_dns: prefix の後の部分）は DNS 名でなければならず、request とともに渡される leaf certificate における dNSName Subject Alternative Name (SAN) [RFC5280] entry と一致しなければならない。request は、署名された request object の x5c JOSE header [RFC7515] に追加される certificate chain の leaf X.509 certificate に含まれる public key に対応する private key で署名されなければならない。Wallet は、署名および X.509 certificate の trust chain を検証しなければならない。public key 以外のすべての Verifier metadata は client_metadata parameter から取得しなければならない。Appendix A で定義される DC API を用いたやり取りでない限り、以下の要件が適用される。Wallet が、たとえば Client Identifier が trusted Client Identifiers のリストに含まれている等により、certificate により認証された Client Identifier を信頼できる場合、client は redirect_uri 値を自由に選択できるようにしてよい。そうでない場合、redirect_uri 値の FQDN は、x509_san_dns: prefix を除いた Client Identifier と一致しなければならない。Client Identifier の例: x509_san_dns:client.example.org。

x509_hash

Client Identifier Prefix が x509_hash の場合、元の Client Identifier（x509_hash: prefix を除いた部分）は hash でなければならず、request とともに渡される leaf certificate の hash と一致しなければならない。request は、[RFC7515] で定義される x5c JOSE header parameter に追加される certificate chain の leaf X.509 certificate の public key に対応する private key で署名されなければならない。x509_hash の値は、DER-encoded X.509 certificate の SHA-256 hash の base64url-encoded 値である。Wallet は、署名および X.509 leaf certificate の trust chain を検証しなければならない。public key 以外のすべての Verifier metadata は client_metadata parameter から取得しなければならない。Client Identifier の例: x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk。

origin

この予約済み Client Identifier Prefix は Appendix A.2 で定義される。Wallet は、この Client Identifier Prefix を requests で受け入れてはならない。Digital Credentials API 上の OpenID4VP では、Credential Presentation の audience は常に origin: で prefix された origin 値となる。たとえば origin:https://verifier.example.com/。

Client Identifier Prefixes openid_federation, decentralized_identifier, verifier_attestation, x509_san_dns, x509_hash を用いるために、Verifiers は private key material を安全に保管できなければならない。これは、ネイティブ apps が通常 public clients であるため、ネイティブ apps の技術設計の変更を要する可能性がある。

他仕様は、追加の Client Identifier Prefixes を定義できる。そのような値には衝突耐性のある名前を用いることが推奨される。

5.10. Request URI Method post

この request は Verifier の Request URI endpoint により処理される。

request は https scheme を用いた HTTP POST method を用い、content type は application/x-www-form-urlencoded とし、Accept header は application/oauth-authz-req+jwt に設定しなければならない。body 内の names と values は UTF-8 を用いてエンコードされなければならない。

Request URI Endpoint への request に含める parameters として、以下を定義する。

wallet_metadata

OPTIONAL。Section 10 で定義される metadata parameters を含む JSON object を格納する string。

wallet_nonce

OPTIONAL。Authorization Request のリプレイ攻撃を緩和するために用いる string 値。受領した場合、Verifier は署名された authorization request object 内の wallet_nonce 値としてそれを用いなければならない。値は base64url-encoded の、新鮮で十分なエントロピーを持つ暗号学的乱数であり得る。

Wallet が Verifier に Request Object の暗号化を要求する場合、Wallet は wallet_metadata parameter 内の jwks parameter を用いて public encryption keys を渡すことが望ましい。Wallet が暗号化された Authorization Response を要求する場合、Wallet は authorization_encryption_alg_values_supported および authorization_encryption_enc_values_supported parameters を用いて、サポートする暗号化 algorithms を指定することが望ましい。

さらに、Client Identifier Prefix が署名された Request Objects を許可する場合、Wallet は request_object_signing_alg_values_supported parameter を通じて Request Object を保護するためのサポートする暗号 algorithms を列挙することが望ましい。逆に、Client Identifier Prefix が署名された Request Objects を許可しない場合、Wallet はこの parameter を含めてはならない。

Request URI Endpoint への request において、追加 parameters を定義して利用してよい。Verifier は認識できない parameters を無視しなければならない。

以下は request の非規範例である。

POST /request HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded

wallet_metadata=%7B%22vp_formats_supported%22%3A%7B%22dc%2Bsd-jwt%22%3A%7B%22sd-jwt_a
lg_values%22%3A%20%5B%22ES256%22%5D%2C%22kb-jwt_alg_values%22%3A%20%5B%22ES256%22%5D%
7D%7D%7D&
wallet_nonce=qPmxiNFCR3QTm19POc8u

5.10.1. Request URI Response

Request URI response は、content type application/oauth-authz-req+jwt を持つ HTTP response でなければならず、body は [RFC9101] で定義される署名済み（optional に暗号化された）request object でなければならない。request object は Section 5 で定義される要件を満たさなければならない。

以下は request object の payload の非規範例である。

{
  "client_id": "x509_san_dns:client.example.org",
  "response_uri": "https://client.example.org/post",
  "response_type": "vp_token",
  "response_mode": "direct_post",
  "dcql_query": {...},
  "nonce": "n-0S6_WzA2Mj",
  "wallet_nonce": "qPmxiNFCR3QTm19POc8u",
  "state" : "eyJhb...6-sVA"
}

Wallet は [RFC9101] で定義されるとおり request を処理しなければならない。加えて、Wallet が POST request で wallet_nonce を渡した場合、Wallet は request object が wallet_nonce claim に当該 nonce 値を含むかを検証しなければならない。含まない場合、Wallet は request processing を終了しなければならない。

Wallet は Request Object から Authorization Request parameters の集合を抽出しなければならない。Wallet は、この Request Object 内の parameters のみを使用しなければならない。たとえ同一 parameter が Authorization Request の query parameter として提供されていたとしても、である。client_id Authorization Request parameter の Client Identifier 値と、Request Object の client_id claim 値は、Client Identifier Prefix を含めて同一でなければならない。これらの条件のいずれかが満たされない場合、Wallet は request processing を終了しなければならない。

その後、Wallet は OAuth 2.0 [RFC6749] で規定されるとおり request を検証する。

5.10.2. Request URI Error Response

Verifier が任意の HTTP error response を返す場合、Wallet は処理を終了しなければならない。

5.11. Verifier Info

Verifier Info parameter は、信頼された第三者によって attested された追加コンテキストまたは metadata を Authorization Request の一部として Verifier が提供できるようにする。これらの入力は、Wallet が policy decisions を適用することの支援、適格性の検証、または同意時に End-User により意味のある情報を提示することなど、多様なユースケースを支える。

各 Verifier Info object は、type identifier、関連データ、および optional に Credential identifiers への参照を含む。これらの attestations の format と意味論は、エコシステムまたは profiles により定義される。

たとえば Verifier は以下を含め得る。

  • 信頼された当局により発行された登録証明書（Verifier が特定の credentials を要求する意図を公的に登録していることを示すため）
  • policy statement（例: 利用目的、保持期間、アクセス権などを記述した署名付き文書）
  • 特定ドメインにおける Verifier の役割の確認（例: EU の Payment Service Directive 2 に基づく認定決済サービス事業者であること）

Verifier Info parameter は optional である。Wallets は、認可判断に用いたりユーザ体験を改善するために用いたりしてよいが、認識できない／サポートしない Verifier Info types は無視すべきである。

5.11.1. Proof of Possession

本仕様は proof of possession の 2 つのモデルをサポートする。

  • claim-bound attestations: attestation は Verifier により署名されないが、Verifier に bind される。正確な binding メカニズムは定義の type により規定される。たとえば JWTs では、sub claim に request 署名に用いた Certificate の distinguished name を含める。binding は client_id parameter を含み得る。
  • key-bound attestations: attestation の proof of possession は、attestation に含まれるか関連付く key を用いて Verifier が署名する。提示要求に署名を bind するため、対応する signature object は nonce と client_id request parameters を含めるべきである。attestation と proof of possession は attachment として渡されなければならない。

Wallet は、profile により定義される場合、そのような proofs を検証しなければならない。また、検証に失敗する attachments は無視するか拒否しなければならない。

6. Digital Credentials Query Language (DCQL)

Digital Credentials Query Language（DCQL、発音は [ˈdakl̩]）は、Verifier が query に合致する Presentations を要求できる JSON-encoded の query language である。Verifier は、要求する Credentials と claims の組み合わせに対して制約をエンコードしてよい。Wallet は、保持する Credentials に対して query を評価し、query に合致する Presentations を返す。

有効な DCQL query は、JSON-encoded object として定義され、以下の top-level properties を持つ。

credentials

REQUIRED。Section 6.1 で定義される Credential Queries の空でない配列。要求される Credentials を指定する。

credential_sets

OPTIONAL。Section 6.2 で定義される Credential Set Queries の空でない配列。要求された Credentials のうち、どれを返すかについて追加制約を指定する。

注: 将来の拡張は、top level および DCQL データ構造の残りの部分に追加 properties を定義し得る。実装は未知の properties を無視しなければならない。

6.1. Credential Query

Credential Query は、合致する 1 つ以上の Credentials の提示を要求する object である。

credentials 内の各 entry は、以下の properties を持つ object でなければならない。

id

REQUIRED。response 内で Credential を識別し、提供される場合は credential_sets の制約でも参照される string。値は英数字、アンダースコア（_）、またはハイフン（-）からなる空でない string でなければならない。同一 Authorization Request 内で、同じ id が複数回存在してはならない。

format

REQUIRED。要求する Credential の format を指定する string。有効な Credential Format Identifier の値は Appendix B で定義される。

multiple

OPTIONAL。この Credential Query で複数の Credentials を返し得るかどうかを示す boolean。省略された場合、デフォルトは false である。

meta

REQUIRED。Verifier が要求する追加 properties を定義する object。これは Credential の metadata と validity data に適用される。この object の properties は Credential Format ごとに定義される。例として Appendix B.3.5 および Appendix B.2.3 にある。空の場合、要求する Credential の metadata または validity には特定の制約を置かない。

trusted_authorities

OPTIONAL。Section 6.1.1 で定義される objects の空でない配列。Verifier が受け入れる、Issuers を認証する authority または trust frameworks を指定する。存在する場合、Wallet が返すすべての Credential は、対応する trusted_authorities 配列に存在する条件の少なくとも 1 つに合致することが望ましい。

Verifier は、受領した presentation の issuer が信頼できるかを自ら検証しなければならない点に留意すること。この機能は主として、拒否される可能性が高い情報を開示しないようにすることでデータ最小化を支援することを目的とする。

require_cryptographic_holder_binding

OPTIONAL。Verifier が Cryptographic Holder Binding proof を要求するかどうかを示す boolean。デフォルトは true、すなわち Cryptographic Holder Binding を備える Verifiable Presentation が要求される。false に設定された場合、Verifier は Cryptographic Holder Binding proof を伴わない Credential を受け入れる。

claims

OPTIONAL。Section 6.3 で定義される objects の空でない配列。要求する Credential 内の claims を指定する。Verifier は、単一 query 内で同一の claim を複数回指してはならない。Wallets は、そのような重複する claim queries を無視すべきである。

claim_sets

OPTIONAL。claims の要素の identifiers の配列（さらに配列の配列）を含む空でない配列。Credential について、どの claims の組み合わせを要求するかを指定する。送信する claims の選択規則は Section 6.4.1 で定義される。

request 内の複数の Credential Queries は、同一の Credential の提示を要求してよい。

6.1.1. Trusted Authorities Query

Trusted Authorities Query は、issuer trust framework または Issuers を認証する authority を識別するのに役立つ情報を表す object である。Credential は、提供される types のいずれかにおいて提供される values のいずれかと合致する場合、Trusted Authorities Query に合致すると識別される。具体的な matching の方法は、以下の type ごとに定義される。

trusted_authorities のメカニズムが適用できない場合でも、claim value matching（例: SD-JWT の iss claim を value matching する）により直接 issuer matching が可能な場合がある点に留意すること。ただし value matching の制約（詳細は Section 6.4.1）により、動作しにくい可能性がある。

trusted_authorities の各 entry は、以下の properties を持つ object でなければならない。

type

REQUIRED。issuer trust framework に関する情報の type を一意に識別する string。本仕様が定義する types は以下に示す。

values

REQUIRED。空でない string の配列。各 string（value）は、用いる Trusted Authorities Query type に固有の情報を含み、issuer、trust framework、または issuer が属する federation を識別できるようにする。

以下に、各 Type Identifiers（string）について、各 value をどう解釈し、どのような matching logic を行うかを記述する。

trusted authorities type の種類に応じて、下層のメカニズムは異なるプライバシー上の影響を持ち得る。より詳細なプライバシー考慮事項は Section 15.10 にある。

6.1.1.1. Authority Key Identifier

  • Type: "aki"
  • Value: [RFC5280] Section 4.2.1.1 で定義される AuthorityKeyIdentifier の KeyIdentifier を base64url でエンコードしたもの。生の byte 表現は、Credential に存在する certificate chain 内の X.509 certificate の AuthorityKeyIdentifier 要素（例: mdoc または SD-JWT の header）と一致しなければならない。chain は単一 certificate から構成され得る。また Credential は X.509 chain 全体または一部を含み得る。

以下は type aki の entry の非規範例である。

{
  "type": "aki",
  "values": ["s9tIpPmhxdiuNkHMEWNpYim8S8Y"]
}

6.1.1.2. ETSI Trusted List

  • Type: "etsi_tl"
  • Value: ETSI TS 119 612 [ETSI.TL] で規定される Trusted List の identifier。ETSI Trusted List は、他の Trusted Lists への参照（trusted lists のリスト）や、対応する service description と X.509 Certificates を持つ Trust Service Providers の entries を含む。合致する Credential の trust chain は、Trusted List またはそのカスケードする Trusted Lists の entries のいずれかに合致する少なくとも 1 つの X.509 Certificate を含まなければならない。

以下は type etsi_tl の entry の非規範例である。

{
  "type": "etsi_tl",
  "values": ["https://lotl.example.com"]
}

6.1.1.3. OpenID Federation

  • Type: "openid_federation"
  • Value: [OpenID.Federation] Section 1 で定義される Entity Identifier。federation 内の entity に bind される。この Entity Identifier はそのエコシステムの任意 entity であり得るが、通常は Trust Anchor の Entity Configuration を持つ entity である。合致する credential から、与えられた Entity Identifier を含む有効な trust path を構成できなければならない。

以下は type openid_federation の entry の非規範例である。

{
  "type": "openid_federation",
  "values": ["https://trustanchor.example.com"]
}

6.2. Credential Set Query

Credential Set Query は、Verifier における特定のユースケースを満たすために 1 つ以上の Credentials を要求する object である。

credential_sets の各 entry は、以下の properties を持つ object でなければならない。

options

REQUIRED。空でない配列。配列内の各 value は、ユースケースを満たす 1 組の Credentials を表す Credential Query identifiers のリストである。options 配列内の各要素の値は、credentials 内の要素を参照する identifiers の空でない配列である。

required

OPTIONAL。この Credential set が Verifier における当該ユースケースを満たすために必須かどうかを示す boolean。省略された場合、デフォルトは true である。

presentation request を送信する前に、Verifier は query の目的、文脈、または理由を End-User に提示すべきである。

6.3. Claims Query

claims の各 entry は、以下の properties を持つ object でなければならない。

id

claim_sets が Credential Query に存在する場合は REQUIRED。そうでない場合は OPTIONAL。特定の claim を識別する string。値は英数字、アンダースコア（_）、またはハイフン（-）からなる空でない string でなければならない。特定の claims 配列内で同じ id が複数回存在してはならない。

path

REQUIRED。値は、Section 7 で定義される claims path pointer を表す空でない配列でなければならない。Credential 内の claim への path を指定する。

values

OPTIONAL。空でない配列であり、strings / integers / boolean values を含み得る。claim の期待値を指定する。values property が存在する場合、Wallet は、claim の type と値の双方が配列内の少なくとも 1 つの要素と完全に一致する場合に限り、その claim を返すことが望ましい。処理規則の詳細は Section 6.4.1 に定義される。

Wallet が value matching を実装し、かつ合致対象の Credential が ISO mdoc-based credential の場合、matching に用いる CBOR value は、[RFC8949] Section 6.1 の助言に従って最初に JSON に変換しなければならない。得られた JSON 値を用いて、上述のとおり values property に対して matching を行う。これらの規則に従う変換が明確に定義されない場合の挙動は、本仕様のスコープ外である。

6.4. Selecting Claims and Credentials

以下のセクションは、claims の選択および credentials の選択に適用されるロジックを記述する。

Selective disclosure をサポートする formats について、これらの規則は、プライバシーに配慮した形で Verifier の要求を満たすための最小データセットを選択することを支援する（追加の考慮事項は Section 15 を参照）。Wallets は、以下の規則に従って選択されていない selectively disclosable claims を送信してはならない。単一の Credential の Presentation は、同一 request 内の別の Credential Query で同一 Credential が追加 claims とともに選択される場合、または追加 claims が selectively disclosable ではない場合、特定の DCQL Credential Query で選択された claims より多くの claims を含んでよい。

6.4.1. Selecting Claims

claims および claim_sets を介した claims 選択には、以下の規則が適用される。

  • claims が存在しない場合、Verifier は selectively disclosable な claims を要求していない。Wallet は提示が必須の claims のみを返さなければならない（例: format が IETF SD-JWT VC の Credential における SD-JWT と Key Binding JWT）。
  • claims は存在するが claim_sets が存在しない場合、Verifier は claims に列挙されたすべての claims を要求している。
  • claims と claim_sets の両方が存在する場合、Verifier は claim_sets に列挙される claims の 1 つの組み合わせを要求している。claim_sets 配列内で提示される options の順序は、返される内容に関する Verifier の優先順位を表す。Wallet は、満たせる最初の option を返すべきである。Wallet がどの option も満たせない場合、Wallet は claims を一切返してはならない。
  • claims が存在しない場合、claim_sets は存在してはならない。
  • Claims Query が claim の values による制約を含む場合、Wallet は、Section 6.3 で定義される values の規則に従って claim の値が一致しないとき、その claim を返さないことが望ましい。すなわち、その claim は Credential 内に存在しないかのように扱われるべきである。この制約の実装は、たとえば Wallet が提示またはユーザ同意前に claim value にアクセスできない場合、または request を Wallet にルーティングする別コンポーネントが claim value にアクセスできない場合など、すべてのケースで可能とは限らない。最終的に、value matching request に従うかどうかは Wallet および／または End-User 次第である。したがって Verifiers は、values により表現される制約をユーザプライバシー改善のための best-effort として扱わなければならないが、セキュリティチェックに依存してはならない。

claim_sets 構文の目的は、Verifier が、ある Credential が要求を満たすための代替手段を記述できるようにすることである。配列の順序は要求を満たす際の Verifier の優先順位を表す。配列の最初の要素が最も優先され、最後の要素が最も優先度が低い。Verifiers は、options の順序に影響を与えるために「最小限の情報開示」の原則を用いるべきである。たとえば年齢証明の要求では、birth_date のような属性よりも age_over_18 のような属性を要求することを優先すべきである。claim_sets 構文は、End-User が選べる options を定義することを意図していない（詳細は Section 6.4.3 を参照）。Wallet は Verifier の優先 option であるため、満たせる最初の option を返すことが推奨される。ただし、逸脱する理由があり得る。理由の非網羅例は以下である。

  • Verifier が情報開示を最小化するように options を並べていないシナリオ
  • 最初の option ではない別の option を返すことが Wallet にとって UX 上の利点を持つ運用上の理由

Wallet がこれらの規則に従って Verifier が要求したすべての claims を提供できない場合、Wallet は該当 Credential を返してはならない。

Selective disclosure をサポートしない Credential Formats については、claims と claim_sets の両方が存在しないケースは「full credential」の提示を要求していると解釈される。これは、すべての claims が提示必須であるためである。

6.4.2. Selecting Credentials

credentials および credential_sets を介した Credentials 選択には、以下の規則が適用される。

  • credential_sets が提供されない場合、Verifier は credentials 内のすべての Credentials の presentations を返すことを要求している。
  • そうでない場合、Verifier は以下を満たす Credentials の presentations を返すことを要求している。
    • credential_sets 配列内の Credential Set Queries のうち、required attribute が true または省略であるすべてのもの、そして
    • optional に、他の Credential Set Queries の任意のもの。

Credential Set Query を満たすために、Wallet は、Credential Set Query 内の options のいずれか 1 つに合致する一組の Credentials の presentations を返さなければならない。

credentials 内で表現された各制約に合致しない Credentials は返してはならない。すなわち、それらは Wallet 内に存在しないかのように扱われる。

Wallet がこれらの規則に従って Verifier が要求した non-optional Credentials をすべて提供できない場合、Wallet は一切の Credential(s) を返してはならない。

6.4.3. User Interface Considerations

本仕様は、異なる sets の claims や Credentials を要求するためのメカニズムを提供するが、Wallet の user interface の詳細（たとえば End-Users がどの combination の Credentials を提示するかを選択できるか、またどのように選択するか）は定義しない。しかし一般に、options 内の複数の sets の Credentials が要求を満たし得る場合、Wallet は End-User に対して提示する Credential(s) の選択肢を提示することが期待される。

7. Claims Path Pointer

claims path pointer は、Credential 内の 1 つ以上の claims を識別する pointer である。claims path pointer は、strings、nulls、そして非負整数からなる空でない配列でなければならない。claims path pointer は処理可能であり、すなわち Credential に適用される。その処理結果が参照される claims である。

7.1. Semantics for JSON-based credentials

本セクションは、JSON-based Credential に適用される claims path pointer の意味論を定義する。

string 値は、対応する key を選択することを示す。null 値は、現在選択されている array(s) のすべての要素を選択することを示す。非負整数は、array 内の対応する index を選択することを示す。path は以下のとおり形成される。

  • 空の配列から開始し、path 全体が形成されるまで以下を繰り返す。
    • object 内の特定 claim を指すには、配列に key（claim 名）を追加する。
    • array 内の要素を指すには、配列に index（非負の 0-based integer）を追加する。
    • array 内のすべての要素を指すには、配列に null 値を追加する。

7.1.1. Processing

詳細には、配列は左から右へ以下のとおり処理される。

  • Credential の root element、すなわち top-level JSON object を選択する。
  • claims path pointer 配列の query を左から右へ処理する。
    • component が string の場合、現在選択されている要素（複数可）それぞれについて、対応する key の要素を選択する。現在選択されている要素のいずれかが object でない場合、処理を中断しエラーを返す。選択中の要素のいずれにも key が存在しない場合、その要素は選択集合から除去する。
    • component が null の場合、現在選択されている array(s) のすべての要素を選択する。現在選択されている要素のいずれかが array でない場合、処理を中断しエラーを返す。
    • component が非負整数の場合、現在選択されている array(s) の対応 index の要素を選択する。現在選択されている要素のいずれかが array でない場合、処理を中断しエラーを返す。選択された array に index が存在しない場合、その array は選択集合から除去する。
    • component がそれ以外の場合、処理を中断しエラーを返す。
    • 現在選択されている要素の集合が空になった場合、処理を中断しエラーを返す。

処理結果は、選択された JSON 要素の集合である。

7.2. Semantics for ISO mdoc-based credentials

本セクションは、ISO mdoc format の credential に適用される claims path pointer の意味論を定義する。

mdoc への claims path pointer は string 型の 2 要素を含む。最初の要素は namespace を参照し、2 番目の要素は data element identifier を参照する。

7.2.1. Processing

詳細には、配列は以下のとおり処理される。

  • claims path pointer がちょうど 2 つの components を含まない、または components のいずれかが string でない場合、処理を中断しエラーを返す。
  • 最初の component が参照する namespace を選択する。namespace が mdoc に存在しない場合、処理を中断しエラーを返す。
  • 2 番目の component が参照する data element を選択する。data element が Credential に存在しない場合、処理を中断しエラーを返す。

処理結果は、CBOR data item としての selected data element value である。

7.3. Claims Path Pointer Example

以下は、JSON-based Credential の非規範的で簡略化された例である。

{
  "name": "Arthur Dent",
  "address": {
    "street_address": "42 Market Street",
    "locality": "Milliways",
    "postal_code": "12345"
  },
  "degrees": [
    {
      "type": "Bachelor of Science",
      "university": "University of Betelgeuse"
    },
    {
      "type": "Master of Science",
      "university": "University of Betelgeuse"
    }
  ],
  "nationalities": ["British", "Betelgeusian"]
}

以下は claims path pointers の例と、それぞれで選択される claims を示す。

  • ["name"]: 値が Arthur Dent の claim name が選択される。
  • ["address"]: sub-claims を値として持つ claim address が選択される。
  • ["address", "street_address"]: 値が 42 Market Street の claim street_address が選択される。
  • ["degrees", null, "type"]: degrees 配列内のすべての type claims が選択される。
  • ["nationalities", 1]: 2 番目の nationality が選択される。

7.4. DCQL Examples

以下は、type 値が https://credentials.example.com/identity_credential であり、claims last_name、first_name、および address.street_address を要求する、format dc+sd-jwt の Credential を要求する DCQL query の非規範例である。

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://credentials.example.com/identity_credential"]
      },
      "claims": [
        { "path": ["last_name"] },
        { "path": ["first_name"] },
        { "path": ["address", "street_address"] }
      ]
    }
  ]
}

追加の、より複雑な例は Appendix D にある。

8. Response

VP Token は、対応する Authorization Request が dcql_query parameter を含むか、または DCQL Query を表す scope parameter を含む場合にのみ返される（Section 5）。

VP Token は、使用された Response Type に応じて Authorization Response または Token Response で返され得る。詳細は Section 5.6 を参照。

Response Type の値が vp_token の場合、VP Token は Authorization Response で返される。Response Type の値が vp_token id_token であり、かつ scope parameter が openid を含む場合、VP Token は Authorization Response で、[SIOPv2] で定義される Self-Issued ID Token と並んで返される。

Response Type の値が code（Authorization Code Grant Type）の場合、VP Token は Token Response で提供される。

期待される挙動は以下の table に要約される。

Table 1: OpenID for Verifiable Presentations response_type values

  • response_type parameter value: vp_token
    • Response containing the VP Token: Authorization Response
  • response_type parameter value: vp_token id_token
    • Response containing the VP Token: Authorization Response
  • response_type parameter value: code
    • Response containing the VP Token: Token Response

VP Token に関する挙動は、その他の個別の Response Type 値、または Response Type 値の組み合わせについては未規定である。

8.1. Response Parameters

VP Token が返される場合、対応する response は以下の parameters を含む。

vp_token

REQUIRED。これは JSON-encoded object であり、key は DCQL query 内の Credential Query に用いられる id 値で、value は対応する Credential Query に合致する 1 つ以上の Presentations の配列である。multiple が省略されるか false に設定される場合、配列は 1 つの Presentation のみを含まなければならない。合致する Credentials が存在しない optional Credential Queries について、JSON-encoded object 内に entry が存在してはならない。各 Presentation は、Appendix B で定義される format に応じて string または object として表現される。Presentations のエンコードには上記と同じ規則が適用される。

code（[RFC6749] より）、id_token（[OpenID.Core] より）、および iss（[RFC9207] より）などの他 parameters は、それぞれの仕様で定義されるとおり response に含められ得る。

追加の response parameters は、[RFC6749] に記述されるとおり、定義して利用してよい。Client は認識できない parameters を無視しなければならない。

以下は、Authorization Request における Response Type 値が vp_token であった場合の Authorization Response の非規範例である。

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
  vp_token=...

8.1.1. Examples

以下は、Section 7.4 に示す DCQL のような request の後、SD-JWT VC format における単一の Verifiable Presentation を含む VP Token の内容の非規範例である（簡潔さのため短縮）。

{
  "my_credential": ["eyJhbGci...QMA"]
}

以下は、Credential Query の multiple が true に設定されているとき、SD-JWT VC format における複数の Verifiable Presentations を含む VP Token の内容の非規範例である（簡潔さのため短縮）。

{
  "my_credential": ["eyJhbGci...QMA", "eyJhbGci...QMA", ...]
}

8.2. Response Mode "direct_post"

Response Mode direct_post は、Wallet が Verifier により制御される endpoint へ HTTP POST request で Authorization Response を送信できるようにする。

これは以下のユースケースに対処するために定義された。

  • Verifier と Wallet が異なるデバイス上にあるため、Wallet は redirect を用いて Authorization Response を Verifier に送信できない。
  • Authorization Response のサイズが user agents の URL 長制限を超えるため、redirect のみに依存するフロー（例: Response Mode fragment）を利用できない。この場合、Response Mode direct_post は、Wallet が backend を持たなくても Presentations を Verifier に伝達するための方法である。

Response Mode は [OAuth.Responses] に従って以下のとおり定義される。

direct_post

この mode では、Authorization Response は、Verifier により制御される endpoint へ HTTP POST request を用いて Verifier に送信される。Authorization Response は、application/x-www-form-urlencoded HTTP content type により定義される形式で request body にエンコードされなければならない。request body 内の parameters はすべて UTF-8 を用いてエンコードされなければならない。Verifier は、後述のとおり response を用いて End-User を Verifier にリダイレクトするよう Wallet に要求できる。

Response Mode direct_post と併用するため、本仕様は以下の新しい Authorization Request parameter を定義する。

response_uri

Response Mode direct_post が用いられる場合は REQUIRED。Wallet が Response Mode direct_post により定義されるとおり HTTP POST request を用いて Authorization Response を送信しなければならない URL。Response URI は、対応する Response Type により定義されるすべての Authorization Response parameters を受け取る。response_uri parameter が存在する場合、redirect_uri Authorization Request parameter は存在してはならない。Response Mode が direct_post のときに redirect_uri Authorization Request parameter が存在する場合、Wallet は invalid_request Authorization Response error を返さなければならない。response_uri の値は、Section 5.9 で定義される規則に従う際に client が redirect_uri として使用を許可される値でなければならない。

注: 本仕様本文が Authorization Request における Redirect URI の使用に言及する場合、その部分の本文は Response Mode direct_post における Authorization Request の Response URI の使用にも適用される。

注: Verifier の user interface（Frontend）を提供するコンポーネントと、Response URI を提供するコンポーネントは、authorization requests を対応する authorization responses にマップできる必要がある。Verifier は、その目的のために state Authorization Request parameter を用いて適切なデータを Authorization Response に追加してよい。詳細は Section 13.3 を参照。

Response Mode direct_post とともに、追加 request parameters を定義して利用してよい。Wallet は認識できない parameters を無視しなければならない。

以下は Response Mode direct_post の payload（Request Object）の非規範例である。

{
  "client_id": "redirect_uri:https://client.example.org/post",
  "response_uri": "https://client.example.org/post",
  "response_type": "vp_token",
  "response_mode": "direct_post",
  "dcql_query": {...},
  "nonce": "n-0S6_WzA2Mj",
  "state": "eyJhb...6-sVA"
}

以下の Authorization Request の非規範例は、上記の Authorization Request Object を request_uri parameter により参照する。Authorization Request は、End-User に対して直接（link として）表示することも、QR Code として表示することもできる。

https://wallet.example.com?
  client_id=https%3A%2F%2Fclient.example.org%2Fcb
  &request_uri=https%3A%2F%2Fclient.example.org%2F567545564

以下は、Verifier の Response URI に対して HTTP POST request で送信される Authorization Response の非規範例である。

POST /post HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded

  vp_token=...&
  state=eyJhb...6-sVA

以下は、Verifier の Response URI に対して HTTP POST request で送信される Authorization Error Response の非規範例である。

POST /post HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded

  error=invalid_request&
  error_description=unsupported%20client_id_prefix&
  state=eyJhb...6-sVA

Response URI が Authorization Response または Authorization Error Response を正常に処理した場合、HTTP status code 200 と Content-Type: application/json を付与し、response body に JSON object を含めて応答しなければならない。

Response Endpoint から Wallet へ返される JSON object で使用するため、本仕様は以下の新しい parameter を定義する。

redirect_uri

OPTIONAL。URI を含む string。この parameter が存在する場合、Wallet は user agent をこの URI へ redirect しなければならない。これにより、Wallet が Authorization Response を Response URI に送信した後、Verifier は Wallet が存在するデバイス上で End-User とのやり取りを継続できる。Verifier は、session fixation（Section 14.2）攻撃を防ぐためにこれを利用できる。Response URI は、成功した Authorization Responses または Error Responses に対する response として redirect_uri parameter を返してよい。

追加の response parameters を定義して利用してよい。Wallet は認識できない parameters を無視しなければならない。

注: redirect_uri を伴わない Response Mode direct_post は、redirect を伴う Response Modes より安全性が低い可能性がある。詳細は Section 14.2 を参照。

Redirect URI の値は、[RFC3986] Section 4.3 で定義される absolute URI であり、Verifier により選択される。Verifier は URL に、新鮮で暗号学的にランダムな値を含めなければならない。この値は、redirect の受信者のみが Authorization Response を取得して処理できるようにするために用いられる。この値は、path component として、fragment として、または URL の parameter として追加できる。128 bits 以上の暗号学的乱数値を用いることが推奨される。実装上の考慮事項は Section 13.3 を参照。

以下は、Response URI で Authorization Response を受信した際に、Verifier が Wallet に返す response の非規範例である（Section 13.3 の response_code parameter を使用）。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "redirect_uri": "https://client.example.org/cb#response_code=091535f699ea575c7937fa5f0f454aee"
}

response に redirect_uri parameter が含まれない場合、Wallet は追加の手順を実行する必要はない。

注: Response Mode direct_post または direct_post.jwt では、Wallet は Authorization Response の送信後に、Verifier から Wallet への callback に応じて UI を変更できる。

Response Endpoint から Wallet への response において、追加 parameters を定義して利用してよい。Wallet は認識できない parameters を無視しなければならない。

8.3. Encrypted Responses

本セクションは、VP Token を含む Authorization Response（例: Response Type の値が vp_token または vp_token id_token の場合）を、payload が Authorization Response parameters を含む JSON object である JWE として [RFC7518] を用いて application level で暗号化する方法を定義する。Authorization Response を暗号化することで、たとえば Authorization Response が front channel（例: browser）経由で返される際に、Authorization Response 内の個人データが漏えいすることを防げる。

Authorization Response を暗号化するため、実装は [RFC7519] で説明される unsigned, encrypted JWT を用いなければならない。

Authorization Response を暗号化する Verifier の public key を取得するため、Wallet は client metadata（例: client_metadata request parameter 内の jwks member、または与えられた Client Identifier Prefix により許可される他メカニズム）から JWKs を用いる。Wallet は、サポートと自らの preference に基づき、各 key の kty（Key Type）、use（Public Key Use）、alg（Algorithm）などの情報に基づいて、Authorization Response を暗号化するための public key を選択する。alg parameter は JWKs 内に存在しなければならない。使用される JWE alg algorithm は、選択された jwk の alg 値と等しくなければならない。選択された public key が kid parameter を含む場合、暗号化された response の JWE は、encrypted response の kid JWE Header Parameter（Section 4.1.6 で定義）に同じ値を含めなければならない。これにより、Verifier は response を暗号化するのに用いられた特定の public key を容易に識別できる。JWE enc content encryption algorithm は、client_metadata request parameter などの client metadata の encrypted_response_enc_values_supported parameter から取得される。明示的に設定されない場合、デフォルト値 A128GCM が許容される。

暗号化された JWT response の payload は、Section 8.1 で定義される response の内容を top-level JSON members として含めなければならない。

以下は、client_metadata request parameter の jwks member に暗号化のための複数の public keys を提供しつつ、暗号化 response を要求している request 内容の非規範例である。

{
  "response_type": "vp_token",
  "response_mode": "dc_api.jwt",
  "nonce": "xyz123ltcaccescbwc777",
  "dcql_query": {
    "credentials": [
      {
        "id": "my_credential",
        "format": "dc+sd-jwt",
        "meta": {
          "vct_values": ["https://credentials.example.com/identity_credential"]
        },
        "claims": [
          { "path": ["last_name"] },
          { "path": ["first_name"] },
          { "path": ["address", "postal_code"] }
        ]
      }
    ]
  },
  "client_metadata": {
    "jwks": {
      "keys": [
        {
          "kty": "EC",
          "kid": "ac",
          "use": "enc",
          "crv": "P-256",
          "alg": "ECDH-ES",
          "x": "YO4epjifD-KWeq1sL2tNmm36BhXnkJ0He-WqMYrp9Fk",
          "y": "Hekpm0zfK7C-YccH5iBjcIXgf6YdUvNUac_0At55Okk"
        },
        {
          "kty": "OKP",
          "kid": "jc",
          "use": "enc",
          "crv": "X25519",
          "alg": "ECDH-ES",
          "x": "WPX7wnwq10hFNK9aDSyG1QlLswE_CJY14LdhcFUIVVc"
        },
        {
          "kty": "EC",
          "kid": "lc",
          "use": "enc",
          "crv": "P-384",
          "alg": "ECDH-ES",
          "x": "iHytgLNtXjEyYMAIGwfgjINZRmLfObYbmjPhkaPD8OiTkJtRHjegTNdH31Mxg4nV",
          "y": "MizXWSqNB7sSt_SNjg3spvaJnmjB-LpxsPpLUaea33rvINL3Mq-gEaANErRQpbLx"
        },
        {
          "kty": "OKP",
          "kid": "bc",
          "use": "enc",
          "crv": "X448",
          "alg": "ECDH-ES",
          "x": "pK5IRpLlX-8XcsRYWHejpzkfsHoDOmAYuBzAC7aTpewWOw_QFHSa64t9p2kuommI8JQQLohS2AIA"
        }
      ]
    },
    "encrypted_response_enc_values_supported": ["A128GCM", "A128CBC-HS256"]
  }
}

上記 request に対する非規範例 response（最初の key に暗号化したもの）は、以下のようになり得る（表示目的のみで改行を追加）。

{
  "response": "eyJhbGciOiJFQ0RILUVTIiwiZW5jIjoiQTEyOEdDTSIsImtpZCI6ImFjIiwiZXBrIjp7Imt
    0eSI6IkVDIiwieCI6Im5ubVZwbTNWM2piaGNhZlFhUkJrU1ZOSGx3Wkh3dC05ck9wSnVmeVlJdWsiLCJ5I
    joicjRmakRxd0p5czlxVU9QLV9iM21SNVNaRy0tQ3dPMm1pYzVWU05UWU45ZyIsImNydiI6IlAtMjU2In1
    9..uAYcHRUSSn2X0WPX.yVzlGSYG4qbg0bq18JcUiDRw56yVnbKR8E7S7YlEtzT00RqE3Pw5oTpUG3hdLN
    4taHZ9gC1kwak8JOnJgQ.1wR024_3-qtAlx1oFIUpQQ"
}

説明のため、以下の JWK は private key の d parameter 値を含んでおり、上記の暗号化された Authorization Response example を復号するために利用できる。

{
  "kty": "EC",
  "kid": "ac",
  "use": "enc",
  "crv": "P-256",
  "alg": "ECDH-ES",
  "x": "YO4epjifD-KWeq1sL2tNmm36BhXnkJ0He-WqMYrp9Fk",
  "y": "Hekpm0zfK7C-YccH5iBjcIXgf6YdUvNUac_0At55Okk",
  "d": "Et-3ce0omz8_TuZ96Df9lp0GAaaDoUnDe6X-CRO7Aww"
}

以下は、上記の暗号化された Authorization Response example の decoded header を示す。

{
  "alg": "ECDH-ES",
  "enc": "A128GCM",
  "kid": "ac",
  "epk": {
    "kty": "EC",
    "x": "nnmVpm3V3jbhcafQaRBkSVNHlwZHwt-9rOpJufyYIuk",
    "y": "r4fjDqwJys9qUOP-_b3mR5SZG--CwO2mic5VSNTYN9g",
    "crv": "P-256"
  }
}

また以下は、上記の暗号化された Authorization Response example の payload を示す。

{
  "vp_token": { "example_credential_id": ["eyJhb...YMetA"] }
}

[ECDH-ES] JWE algorithms（[RFC7518] Section 4.6）においては、apu と apv の値は content encryption key を導出する key derivation process への入力である点に留意すること。使用される algorithm に関わらず、これらの値は常に AEAD tag 計算の一部であるため、暗号化された response に bind される。

注: 暗号化に関して、実装者は JOSE を通じて多様な options を利用できる。これには、[I-D.ietf-jose-hpke-encrypt] で詳細化される Hybrid Public Key Encryption (HPKE) の利用も含まれる。

8.3.1. Response Mode "direct_post.jwt"

本仕様は、Section 8.2 で定義される Response Mode direct_post の上に暗号化を適用できる、新しい Response Mode direct_post.jwt も定義する。本セクションで特に指定しない限り、Section 8.2 に記述されたメカニズムが適用される。

Response Mode direct_post.jwt は、Section 8.2 で定義されるとおり Verifier に redirect する代わりに、Wallet が HTTP POST request を用いて Authorization Response を送信するようにする。Wallet は、Section 8.3 で定義される JWT を含む response parameter を、application/x-www-form-urlencoded content type を用いた HTTP POST request の body に追加する。body 内の names と values は UTF-8 を用いてエンコードされなければならない。

Wallet が暗号化 response を生成できない場合、Wallet は Section 8.2 に従い暗号化なしの error response を送信してよい。

以下は response の非規範例である（表示目的のみで、省略した内容は ellipses で示す）。

POST /post HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded

response=eyJra...9t2LQ

以下は、上記例で用いられる JWT の payload を、暗号化および base64url encoding の前の状態で示した非規範例である（表示目的のみで、内容は省略を含む）。

{
  "vp_token": { "example_jwt_vc": ["eY...QMA"] }
}

8.4. Transaction Data

transaction data mechanism は、たとえば支払 transaction を完了する、または QES（Qualified Electronic Signatures）を用いて特定の document(s) に署名するために、ユーザの identification/authentication とユーザの authorization を bind することを可能にする。これは、ユーザの identification/authentication の手段として提示される Credential に対する proof of possession のために用いられる、ユーザが管理する key を用いて、ユーザ authorization に用いられる transaction data に署名することで達成される。

request 内の transaction_data parameter を受領した Wallet は、当該 data の表現または参照を、対応する Credential presentation に含めなければならない。これをどのように行うかは transaction data type に固有である。Credential Formats は Appendix B にあるように、transaction data の取り扱いに関する推奨事項を示し得る。

Wallet が transaction_data parameter をサポートしない場合、それを含む request を受領した際に error を返さなければならない。

8.5. Error Response

error response は [RFC6749] に定義される規則に従うが、以下の追加の明確化を行う。

invalid_scope

要求された scope 値が無効、未知、または不正な形式である。

invalid_request

以下のいずれかに該当する。

  • request が dcql_query parameter と、DCQL query を参照する scope parameter の双方を含む。
  • request が vp_token Response Type を用いているが、dcql_query parameter も DCQL query を参照する scope parameter も含まない。
  • Wallet が Authorization Request で渡された Client Identifier Prefix をサポートしない。
  • request に渡された Client Identifier がその Client Identifier Prefix に属していない、または特定 prefix の要件が違反された（例: Client Identifier Prefix https を用いて署名なし request が送られた）。

invalid_client

以下のいずれかに該当する。

  • Section 5.1 で定義される client_metadata parameter が存在するが、Wallet が Client Identifier を認識し、それに紐づく metadata を知っている。
  • Client Identifier に基づき Verifier の pre-registered metadata が見つかったが、client_metadata parameter も存在する。

access_denied

以下のいずれかに該当する。

  • Wallet が Authorization Request を満たすための要求された Credentials を保持していなかった。
  • End-User が要求された Credentials を Verifier と共有することに同意しなかった。
  • Wallet が End-User の認証に失敗した。

本書は、以下の追加の error codes および error descriptions も定義する。

vp_formats_not_supported

Wallet が、vp_formats_supported registration parameter に含まれるものなど、Verifier により要求された formats のいずれもサポートしない。

invalid_request_uri_method

request_uri_method request parameter の値が get でも post でもない（case-sensitive）。

invalid_transaction_data

transaction_data 構造内の少なくとも 1 つの object について、以下のいずれかが真である。

  • unknown または unsupported の transaction data type 値を含む。
  • 既知の type の object だが unknown fields を含む。
  • transaction data type に対して誤った type の fields を含む。
  • transaction data type に対して無効な値の fields を含む。
  • transaction data type に必須の fields が欠落している。
  • credential_ids が一致しない、または
  • 参照された Credential(s) が Wallet で利用できない。

wallet_unavailable

Wallet が利用不能であり、request に応答できないように見える。これは、user agent が Wallet を起動できず、別コンポーネントが request を受領する一方、End-User が Verifier website 上で journey を継続したい状況で有用となり得る。たとえば、platform が URI を platform intent に変換して Wallet を起動しない場合に、Wallet provider が提供する claimed HTTPS URIs を用いるときに該当する。この場合、Wallet provider は Authorization Error Response を Verifier に返し、user agent を Verifier website に redirect し得る。

8.6. VP Token Validation

Verifiers は、以下の方法で VP Token を検証しなければならない。

  • Section 8.1 で定義されるとおり、VP Token の format を検証する。
  • 要求された特定の Credential Format に従って、個々の Presentations を確認する。
    • Presentation と Credential の integrity と authenticity を検証する。
    • 返された Credential(s) が Authorization Request 内の query で定義されるすべての基準を満たすことを検証する（例: presentation に含まれる Claims）。
    • 特に要求しない限り、すべての Presentations が Holder Binding の cryptographic proof を含むこと（すなわち Verifiable Presentations であること）を検証する。
    • Verifiable Presentations について、Section 14.1 で記述される replay 防止のための checks を含めて Holder Binding を検証する。
    • 適用可能な場合、revocation checks など、Verifier が属する trust frameworks などの trust requirements の集合に基づく Verifier の policy により要求される checks を実行する。
    • Section 6.4 で記述されるとおり、返された Presentations の集合が Verifier の request で定義される要件をすべて満たすことを確認する。

個々の Presentation に関連する checks のいずれかが失敗した場合、影響を受ける Presentation は破棄されなければならない。VP Token または全体 response に関する checks のいずれかが失敗した場合、VP Token は拒否されなければならない。

9. Wallet Invocation

Verifier は、以下のいずれかのメカニズムを用いて Wallet を起動できる。

  • authorization_endpoint としての Custom URL scheme（例: Section 13.1.2 で定義される openid4vp://）
  • authorization_endpoint としての URL（Domain-bound Universal Links / App link を含む）

cross device flow の場合、上記 options のいずれかを、End-User が Wallet または user-device 上の任意の camera application でスキャンできる QR code として提示してよい。

Wallet は、Appendix A で記述される Digital Credentials API を用いて web または native app から起動されることもある。Appendix A で詳細に述べられているとおり、DC API はプライバシー、セキュリティ（Section 14.2 を参照）、および user experience 上の利点（特に End-User が複数の Wallets を持つケース）を提供する。

10. Wallet Metadata (Authorization Server Metadata)

本仕様は、Verifier が、protocol exchange で利用するために Wallet がサポートする Credential formats、proof types、および algorithms をどのように判定できるかを定義する。

10.1. Additional Wallet Metadata Parameters

本仕様は、[RFC8414] に従って新しい metadata parameters を定義する。

vp_formats_supported

REQUIRED。name/value pairs の list を含む object。name は Credential Format Identifier であり、value は Wallet がサポートする format-specific parameters を定義する。利用可能な specific values については Appendix B を参照。Deployments は、Issuers、Holders および Verifiers がすべて新しい format を理解することを条件に、サポートされる formats を拡張できる。

以下は vp_formats_supported parameter の非規範例である。

"vp_formats_supported": {
  "jwt_vc_json": {
    "alg_values": [
      "ES256K",
      "ES384"
    ]
  }
}

client_id_prefixes_supported

OPTIONAL。Wallet がサポートする Client Identifier Prefixes の values を含む、空でない string 配列。本仕様で定義される values は、pre-registered（Client Identifier Prefix を用いない場合の挙動を表す）、redirect_uri、openid_federation、verifier_attestation、decentralized_identifier、x509_san_dns、および x509_hash である。省略された場合、デフォルト値は pre-registered である。本仕様の profiles または extensions で定義される場合、他の values を使用してよい。

追加の Wallet metadata parameters は、[RFC8414] に記述されるとおり、定義して利用してよい。Verifier は認識できない parameters を無視しなければならない。

10.2. Obtaining Wallet's Metadata

本仕様を利用する Verifier には、Wallet の metadata を取得するための複数の options がある。

  • Verifier が、たとえば [RFC8414] または out-of-band mechanisms を用いて Wallet の metadata を動的に取得する。詳細は Section 10 を参照。
  • Verifier が、Wallet の metadata の static set を事前に取得している。例は Section 13.1.2 を参照。

11. Verifier Metadata (Client Metadata)

Verifier metadata を伝達するため、[RFC7591] の Section 2 で定義される Client metadata を用いる。

本仕様は、protocol exchange で利用するために Verifier がサポートする Credential formats、proof types、および algorithms を Wallet がどのように判定できるかを定義する。

11.1. Additional Verifier Metadata Parameters

本仕様は、Verifier により使用されるべき新しい Client metadata parameters を [RFC7591] に従って以下のとおり定義する。

vp_formats_supported

REQUIRED。name/value pairs の list を含む object。name は Credential Format Identifier であり、value は Verifier がサポートする format-specific parameters を定義する。利用可能な specific values については Appendix B を参照。Deployments は、Issuers、Holders および Verifiers がすべて新しい format を理解することを条件に、サポートされる formats を拡張できる。

追加の Verifier metadata parameters は、[RFC7591] に記述されるとおり、定義して利用してよい。Wallet は認識できない parameters を無視しなければならない。

12. Verifier Attestation JWT

Verifier Attestation JWT は、Wallet が Verifier を安全かつ柔軟に認証できるよう特別に設計された JWT である。Verifier Attestation JWT は、Verifier の authentication および authorization の目的で Wallets が信頼する party により Verifier に発行される。信頼がどのように確立されるかは本仕様の範囲外である。すべての Verifier は public key に bind され、Verifier は常に、この key に対する proof of possession とともに Verifier Attestation JWT を提示しなければならない。Client Identifier Prefix verifier_attestation の場合、authorization request はこの key で署名され、これが proof of possession となる。

Verifier Attestation JWT は以下の claims を含まなければならない。

  • iss: REQUIRED。この claim は Verifier Attestation JWT の issuer を識別する。iss 値は issuer の public key を取得するために使用してよい。Wallet と Issuer の間でどのように trust が確立されるか、および attestation の署名を検証するための public key をどのように取得するかは本仕様の範囲外である。
  • sub: REQUIRED。この claim の値は、Credential request を行う client の client_id でなければならない。
  • iat: OPTIONAL。[RFC7519] で定義される構文を用いて、Verifier Attestation JWT が発行された時刻を表す number。
  • exp: REQUIRED。[RFC7519] で定義される構文を用いて、Verifier Attestation JWT が失効する時刻を表す number。Wallet は、systems 間の許容される clock skew を考慮したうえで、expiration time が過ぎた Verifier Attestation JWT を拒否しなければならない。
  • nbf: OPTIONAL。この時刻より前は token を処理のために受け入れてはならないことを表す number。
  • cnf: REQUIRED。[RFC7800] で定義される confirmation method を含む claim。[RFC7800] Section 3.2 で定義される JSON Web Key [RFC7517] を含まなければならない。この claim は、Verifier Attestation JWT を提示する際に Verifier が、対応する private key の possession を証明しなければならない public key を決定する。この追加の security measure は、Verifier が trusted issuer から Verifier Attestation JWT を取得し、それを issuer に依存せずに長期間利用できる一方で、敵対者が捕捉した attestation を replay して Verifier になりすますリスクを低減する。

追加の claims は、[RFC7519] に記述されるとおり、Verifier Attestation JWT に定義して利用してよい。Wallet は認識できない claims を無視しなければならない。

本仕様に準拠する Verifier Attestation JWTs は、Appendix E.6.1 で定義される media type application/verifier-attestation+jwt を用いなければならない。

Verifier Attestation JWT は typ JOSE header を verifier-attestation+jwt に設定しなければならない。

Verifier Attestation JWT は、JWS signed object の header（JOSE header）で伝達されてもよい。

本仕様は、JWT をそのような header に追加できるようにする JOSE header を導入する。以下のとおりである。

  • jwt: この JOSE header は JWT を含まなければならない。\ 本仕様の文脈では、その JWT は typ JOSE header を verifier-attestation+jwt に設定しなければならない。

13. Implementation Considerations

13.1. Static Configuration Values of the Wallets

本セクションは、Wallets の static configuration values を定義する本仕様の profiles を列挙し、Verifier が Dynamic Discovery を実行できない場合に使用できる static configuration values の 1 セットを定義する。

13.1.1. Profiles that Define Static Configuration Values

以下は、Wallets の static configuration values を定義する profiles の list である。

  • OpenID4VC High Assurance Interoperability Profile 1.0
  • JWT VC Presentation Profile

13.1.2. A Set of Static Configuration Values bound to openid4vp://

以下は、Authorization Endpoint として custom URL scheme openid4vp:// に bind され、サポートされる Response Type として vp_token parameter を用いて利用できる static configuration values の set の非規範例である。

{
  "authorization_endpoint": "openid4vp:",
  "response_types_supported": [
    "vp_token"
  ],
  "vp_formats_supported": {
    "dc+sd-jwt": {
      "sd-jwt_alg_values": [
        "ES256"
      ],
      "kb-jwt_alg_values": [
        "ES256"
      ]
    },
    "mso_mdoc": {}
  },
  "request_object_signing_alg_values_supported": [
    "ES256"
  ]
}

13.2. Nested Presentations

本仕様は、別の Presentation の内側に入れ子になった Presentation の提示をサポートしない。

13.3. Response Mode direct_post

Response Mode direct_post を使用する際の、Verifier の異なる components（特に Frontend と Response URI）間の相互作用の設計は、Verifier と Wallet の間の interface に影響しないため、Verifier の裁量に委ねられる。

実装者を支援するため、本セクションは Section 14 に示される Security Considerations を満たす可能な設計を概説する。

Figure 3 は、その設計の sequence diagram を示す。

+--------+   +------------+           +---------------------+                 +----------+
|End-User|   |  Verifier  |           |  Verifier           |                 |  Wallet  |
|        |   |            |           |  Response Endpoint  |                 |          |
+--------+   +------------+           +---------------------+                 +----------+
    |              |                            |                                  |
    |   interacts  |                            |                                  |
    |------------->|                            |                                  |
    |              |  (1) create nonce          |                                  |
    |              |-----------+                |                                  |
    |              |           |                |                                  |
    |              |<----------+                |                                  |
    |              |                            |                                  |
    |              |  (2) initiate transaction  |                                  |
    |              |--------------------------->|                                  |
    |              |                            |                                  |
    |              |  (3) return transaction-id & request-id                       |
    |              |<---------------------------|                                  |
    |              |                            |                                  |
    |              |  (4) Authorization Request                                    |
    |              |      (response_uri, nonce, state, dcql_query)                 |
    |              |-------------------------------------------------------------->|
    |              |                            |                                  |
    |              End-User Authentication / Consent                               |
    |              |                            |                                  |
    |              |                            | (5) Authorization Response       |
    |              |                            |     (VP Token, state)            |
    |              |                            |<---------------------------------|
    |              |                            |                                  |
    |              |                            | (6) Response                     |
    |              |                            | (redirect_uri with response_code)|
    |              |                            |--------------------------------->|
    |              |                            |                                  |
    |              |  (7) Redirect to the redirect URI (response_code)             |
    |              |<--------------------------------------------------------------|
    |              |                            |                                  |
    |              |  (8) fetch response data   |                                  |
    |              |     (transaction-id, response_code)                           |
    |              |--------------------------->|                                  |
    |              |                            |                                  |
    |              |                            |                                  |
    |              |  (9) response data         |                                  |
    |              |     (VP Token)             |                                  |
    |              |<---------------------------|                                  |
    |              |                            |                                  |
    |              |  (10) check nonce          |                                  |
    |              |-----------+                |                                  |
    |              |           |                |                                  |
    |              |<----------+                |                                  |
Figure 3: Reference Design for Response Mode direct_post

(1) Verifier は、少なくとも 16 bytes の新鮮で暗号学的にランダムな bytes を十分な entropy で生成し、session に紐づけ、base64url encoding することで nonce 値を生成する。

(2) Verifier は Response URI で新しい transaction を開始する。

(3) Response URI は transaction をセットアップし、transaction-id と request-id として指定される、十分な entropy を持つ 2 つの新鮮で暗号学的にランダムな numbers を返す。これらの値は、authorization response を識別する（request-id）こと、および Verifier のみが Authorization Response data を取得できることを保証する（transaction-id）プロセスで使用される。

(4) 続いて Verifier は、(1) で作成した nonce 値と、state としての request-id を付して Authorization Request を Wallet に送信する。

(5) End-User を認証し、要求された Credentials を共有することへの同意を得た後、Wallet は vp_token と state parameters を伴う Authorization Response を Verifier の response_uri に送信する。

(6) Verifier の Response URI は、state 値が有効な request-id かどうかを確認する。そうであれば、対応する transaction-id に紐づけて Authorization Response data を保存する。続いて、十分な entropy を持つ新鮮で暗号学的にランダムな number として response_code を生成し、これも対応する Authorization Response data に紐づける。続いて、response_code を含む redirect_uri を Wallet に返す。

注: Verifier の Response URI が redirect_uri を返さない場合、Wallet 側の処理はその step で停止する。Verifier は redirect を待たずに Authorization Response を取得することが想定されている（step 8 を参照）。

(7) Wallet は user agent を Verifier（redirect_uri）へ送る。Verifier は Request を受信し、response_code parameter を抽出する。

(8) Verifier は、session から response_code と transaction-id を Response URI に送信する。

  • Response URI は transaction-id を用いて一致する Authorization Response data を検索し、これにより Verifier の session に紐づく transaction-id が暗黙的に検証される。
  • Authorization Response が見つかった場合、Response URI は response_code が step (6) でこの Authorization Response に紐づけられていたかを確認する。
  • 注: Verifier の Response URI が step (6) で redirect_uri を返さなかった場合、Verifier は、Authorization Response が利用可能になるまで、transaction-id を用いて Response URI に定期的に問い合わせる。

(9) Response URI は、後続処理のため VP Token を Verifier に返す。

(10) Verifier は、step (9) の VP Token 内の Credential(s) に受領した nonce が、session の nonce 値に対応するかを確認する。Verifier は VP Token を消費し、session 内の transaction-id、request-id、および nonce を無効化する。

13.4. Pre-Final Specifications

実装者は、本仕様がまだ final ではない複数の仕様を使用していることを認識すべきである。それらの仕様は以下である。

  • OpenID Federation 1.0 draft -43 [OpenID.Federation]
  • SIOPv2 draft -13 [SIOPv2]
  • Selective Disclosure for JWTs (SD-JWT) draft -22 [I-D.ietf-oauth-selective-disclosure-jwt]
  • SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -09 [I-D.ietf-oauth-sd-jwt-vc]
  • Fully-Specified Algorithms for JOSE and COSE draft -13 [I-D.ietf-jose-fully-specified-algorithms]

本仕様が参照する仕様に破壊的変更が入ることは想定されていないが、万一それが起きた場合でも、OpenID4VP implementations は、profile または本仕様の新 version により更新されない限り、final versions よりも上記で特定される versions を優先して使用し続けるべきである。

14. Security Considerations

14.1. Preventing Replay of Verifiable Presentations

攻撃者は、（たとえば）以前の Authorization Response から得た Presentations を別の Authorization Response に注入することで、それらの Verifiable Presentation を元に提示した End-User になりすまそうとする可能性がある。Holder Binding は、このような攻撃を防ぐことを目的とする。

14.1.1. Presentations without Holder Binding Proofs

定義上、Holder Binding のない Presentations（Section 5.3 を参照）は replay に対する保護を提供しない。Holder Binding のない Presentations を消費する Verifier は、Holder が第三者（例: Verifier の役割を演じること）から Credential を入手した可能性、および Holder が Credential の subject ではない可能性というリスクを受容する。

ユースケース、Verifier のリスク評価、そして取り得る外部の validation measures に応じて、このリスクは許容可能であり得る。

14.1.2. Verifiable Presentations

Verifiable Presentations については、本仕様の実装者は replay attacks を検知・防止するために本セクションで定義される controls を実装しなければならない。

Verifiable Presentation における cryptographic proof of possession は、Wallet により intended audience（Verifier の Client Identifier）および対応する transaction（Section 5.2 で定義される、Authorization Request 内の nonce parameter により識別される）に bind されなければならない。Verifier はこの binding を検証しなければならない。

Wallet は、VP Token 内で Verifier に返される各 Verifiable Presentation を、対応する Authentication Request の client_id と nonce 値に紐づけなければならない。

Verifier は、Authorization Response 内の個々の Verifiable Presentation を検証し、それが対応する Authorization Request で使用した client_id および nonce parameter の値に紐づいていることを保証しなければならない。response 内のいずれかの Verifiable Presentation が正しい nonce 値を含まない場合、その response は拒否されなければならない。

client_id は、意図された相手以外への Verifiable Presentations の replay を検知するために使用される。これにより Verifiers は Verifiable Presentation を拒否できる。nonce 値は Verifiable Presentation を特定の authentication transaction に bind し、特に Presentation が front-channel 経由で渡される flows において flow への Presentation 注入を検知できるようにする。

注: Verifiable Presentations の formats や signature/proof schemes は、intended audience および session binding を表現する方法が異なる。claims を用いてそれらの値を直接表現するものもあれば、cryptographic proofs の計算に値を取り込むものもある。formats 間で naming conventions も異なる。各 presentation の format は request 内で Verifier により定義される。

以下は、Credential Format Identifier jwt_vc_json による request に従う Verifiable Presentation の payload の非規範例である。

{
  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "aud": "s6BhdRkqt3",
  "nonce": "343s$FSFDa-",
  "nbf": 1541493724,
  "iat": 1541493724,
  "exp": 1573029723,
  "vp": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": ["VerifiablePresentation"],
    "verifiableCredential": [""]
  }
}

上記の例では、要求された nonce 値は nonce として含まれ、client_id は Verifiable Presentation の proof における aud 値として含まれる。

以下は、proof property を持たない Credential Format Identifier ldp_vc による request に従う Verifiable Presentation の非規範例である。

{
  "@context": [ ... ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [ ... ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    "challenge": "343s$FSFDa-",
    "domain": "x509_san_dns:client.example.org",
    "proofValue": "z2iAR...3oj9Q8"
  }
}

上記の例では、要求された nonce 値は challenge として含まれ、client_id は Verifiable Presentation の proof における domain 値として含まれる。

14.2. Session Fixation

session fixation attack を実行するため、攻撃者は自身が制御するデバイス上で Verifier を用いて process を開始し、Authorization Request を捕捉して、victim のデバイスへ relay する。その後、攻撃者は自身の Verifier 上で process を完了しようと定期的に試みる。これにより攻撃者側デバイス上の Verifier は Authorization Response の取得と検証を試みることになる。

この種の攻撃は、Response Mode fragment で実装された flows に対しては不可能である。Wallet は常に、Wallet が存在する同一デバイス上の redirect endpoint に VP Token を送るためである。これは、攻撃者が自身のデバイス上の Verifier から有効な Authorization Request を抽出し、victim に victim のデバイス上で同じ Authorization Request を実行させることはできても、通常、攻撃者が resulting VP Token を入手する方法がないことを意味する。

しかし Response Mode direct_post は、この攻撃に対して脆弱である。結果が、Wallet から out-of-band で Verifier の Response URI に送られるからである。

この種の攻撃は、Response Mode direct_post が redirect URI と併用される場合に検知できる。redirect URI により、Wallet は transaction が完了したデバイス上の Verifier frontend へ flow を redirect する。Verifier の Response URI は、Wallet に返す redirect URI に新鮮な secret（Response Code）を含めなければならず、さらに Verifier の Response URI は、frontend が Authorization Response を取得する際に対応する Response Code を渡すことを要求しなければならない。これにより、攻撃者が Response Code にアクセスできない限り session fixation attacks は阻止される。

この保護技術は cross-device scenarios には適用できないことに留意すること。Wallet が使用する browser は元の session を持たないためである。同様に、Wallet が presentation request で使用された browser と異なる browser を用いる same-device scenarios（例: 複数の browsers がインストールされたデバイス）にも適用できない。そこでも元の session は利用できない。Appendix A は、web/app platform APIs を用いた代替の Wallet invocation method を提供し、これらの問題の多くを回避する。

追加の実装上の考慮事項は Section 13.3 を参照。

redirect URI が提供する追加の保護なしに Response Mode direct_post を使用する場合、Verifier には session context がなく、session fixation attempts を検知できない。flow のセキュリティを強化するための mechanisms を Verifiers が実装することが推奨される。可能な attacks と mitigations の詳細は [I-D.ietf-oauth-cross-device-security] を参照。

14.3. Response Mode "direct_post"

14.3.1. Validation of the Response URI

Wallet は、Authorization Response 内の data が Response URIs を通じて漏えいしないことを保証しなければならない。pre-registered Response URIs を使用する場合、Wallet は [RFC9700] で定義される redirect URI validation の best practices に従わなければならない。Wallet は、Client Identifier Prefix を Client Authentication および request の integrity protection と併用することで、特定の Verifier により提供される Response URI への trust を確立してよい。

14.3.2. Protection of the Response URI

Verifier は、受領した state parameter の値が最近の Authorization Request に対応することを確認することで、偶発的な requests から自らの Response URI を保護するべきである。

14.3.3. Protection of the Authorization Response Data

本仕様は、Verifier の Response URI が、他の Verifier components が Authorization Response data を取得（および後続で処理）するための internal interface を提供することを想定する。攻撃者は、internal interface を通じて data を探索することで、Verifier の Response URI から Authorization Response Data を取得しようとする可能性がある。これは、personally identifiable information を含み得る有効な Presentations の漏えいにつながり得る。

本仕様の実装は、この internal interface に対する偶発的な requests を防ぐ security mechanisms を備えなければならない。この要件を満たす implementation options の例には、以下が含まれる。

  • Verifier 内の異なる parts 間の Authentication
  • 2 つの暗号学的にランダムな numbers\ 1 つ目は Wallet と Verifier の間の state を管理するために使用し、2 つ目は、正当な Verifier component のみが Authorization Response data を取得できることを保証するために使用する。

14.4. End-User Authentication using Credentials

Credential 内の claim を用いて End-User を認証しようとする Clients は、この claim が End-User にとって安定していること、かつ locally unique であり、Credential Issuer 内で別の End-User に再割り当てされないことを保証しなければならない。そのような claim は、global uniqueness を確保し、攻撃者が別の Credential Issuer から同一の claim を入手して正当な End-User になりすます攻撃を防ぐため、Credential Issuer identifier と組み合わせてのみ使用されなければならない。

14.5. Encrypting an Unsigned Response

暗号化された Authorization Response には追加の integrity protection がないため、攻撃者は Authorization Response parameters を改ざんし、Verifier 向けに新しい暗号化済み Authorization Response を生成できる可能性がある。暗号化は Verifier の public key（request/response に対して ephemeral でない場合、広く知られている可能性が高い）を用いて行われるためである。これには新しい VP Token を注入することも含まれる点に留意すること。VP Token の contents は integrity protected であるため、VP Token の改ざんは Verifier により検知可能である。詳細は Section 14.1 を参照。

14.6. TLS Requirements

実装は [BCP195] に従わなければならない。

TLS が使用される場合は常に、[RFC6125] に従って TLS server certificate check を実行しなければならない。

14.7. Incomplete or Incorrect Implementations of the Specifications and Conformance Testing

セキュリティ上の利点を完全に得るには、本仕様および underlying specifications の実装が、完全かつ正確であることが重要である。

OpenID Foundation は、実装が正しく conformant であることを確認するために使用できる tools を提供している。

https://openid.net/certification/conformance-testing-for-openid-for-verifiable-presentations/

14.8. Always Use the Full Client Identifier

Client Identifier Prefix を用いる Verifiers と、Prefix を用いない Verifiers を混同すると攻撃につながり得る。したがって Wallets は、Wallet の文脈またはその responses の中で client を識別するために、提供されている場合は prefix を含む full Client Identifier を常に使用しなければならない。これは特に、[RFC6749] および Verifier に返される presentation 内で Client Identifier が使用される箇所を指す。

14.9. Security Checks on the Returned Credentials and Presentations

Section 6.4 で示されるとおり、Verifier は claims level および Credential level の両方で様々な constraints を指定できるが、Verifier は Wallet がこれらの constraints を強制することに依存してはならない。Wallet は Verifier により制御されていないため、Verifier は返される Credentials および Presentations に対して自ら security checks を実施しなければならない。

15. Privacy Considerations

多くのプライバシー上の考慮事項は、特定の Presentation で使用される Credential format およびそれに関連する proof type に固有である。

本セクションは、presentation protocol に固有のプライバシー上の考慮事項に焦点を当てつつ、credential formats、Wallet behavior、および Verifier practices に関連する横断的な concerns も扱う。

Wallet providers と Verifiers は、data leakage、user tracking、およびその他のプライバシー上の害のリスクを軽減するため、本セクションのプライバシー考慮事項を考慮に入れる必要がある。

Wallets は、いかなる Verifiable Credential または Presentation を Verifier に開示する前、または error を返す前に、End-User から明示的で十分な情報に基づく同意を得るべきである。

Wallet 内の transaction history および data は、End-User が同意した場合、または別の legal basis がある場合を除き、End-User 以外の誰からもアクセスできるべきではない。

15.3. Purpose Legitimacy

Verifier は、要求している情報を収集する目的が十分に具体的であり、収集前に伝達されていることを保証するべきである。たとえば、目的は Wallet に送られる presentation request の前、またはその中で End-User に示される。

Wallet が、Verifier が権限のない data を要求している兆候を持つ場合、Wallet は End-User に警告するか、場合によっては処理を停止するべきである。

15.4. Selective Disclosure

Selective disclosure は、Credential に含まれるすべての claims を開示することなく、必要な特定情報のみを共有できる data minimization technique である。

DCQL は、Verifier が関心のある claims を指定できるようにし、Wallet が Verifier の request に関連する claims のみを開示できるようにすることで selective disclosure を促進する。

一部の Credential formats は selective disclosure をサポートしており、salted-hash に基づく approach は一般的な手法の一つである。

15.4.1. DCQL Value Matching

DCQL の values を用いて claims の期待値を照合する場合、特定の Credential 内の claim が値に一致したか否かという事実自体が、claim value に関する情報を既に漏えいし得る。したがって Wallets は、values を処理する際に claim value に関する情報を漏えいしないよう予防措置を講じなければならない。特に、以下を含めるべきである。

  • response において、Verifier が「End-User が Credential の開示に同意しなかった」場合と「claim value が期待値に一致しなかった」場合を区別できないようにすること
  • values mismatch により Wallet が response を送れない場合であっても、response を送る前に何らかの End-User interaction を要求することで、End-User の同意なしに data が Verifier に漏れる repeated または “silent” requests を防止すること

ここに列挙した両 case において、error response を返すことも values の処理結果に関する情報を漏えいし得る点を考慮する必要がある。

15.4.2. Strictly Necessary Claims

Verifiers は、明示された目的を満たすために必要な最小限の claims と Credentials のみを要求する DCQL queries を使用するべきである。

15.5. Verifier-to-Verifier Unlinkable Presentations

selective disclosure を用いて Credential から限定された claims だけを Verifier に開示する場合でも、Presentation が別 session の別 Presentation と link されたり、別 Verifier への Presentation と link されたりする方法が存在する。たとえば SD-JWT や mdoc のような Credential formats では、Credential 上の Issuer signature や、Credential が bind される public key が、Credential を異なる Presentations や sessions 間で link する手がかりを Verifier に与え得る。このような linking を避けるため、Wallet は、link を制限する目的でそれぞれに固有の Issuer signatures と関連 public keys を持つ複数の Credential instances を用いることができる。例えば以下である。

  • Wallet は、ある Verifier への Presentation で issued Credential instance を 1 回だけ使用した後にその Credential を破棄することで、上記の基盤による linking が起こることを回避できる。
  • Wallet は、特定 instance に限定利用 policy を適用し、Verifier-to-Verifier linkability を避けるため、同一 Verifier にのみ提示できるようにすることもできる。

salted-hash に基づく selective disclosure mechanisms における unlinkability に関する相当量の議論が [I-D.ietf-oauth-selective-disclosure-jwt] Section 10.1 に示されている。重要な unlinkability properties を達成するための技法として言及されるものの一つに batch issuance があり、これは [OpenID4VCI] でサポートされる。個々の Credentials は 1 回だけ提示される。

15.6. No Fingerprinting of the End-User

Verifier は、End-User の wallet との相互作用で利用可能となり得る metadata に基づいて End-User を fingerprinting しようとするべきではない。

Wallet は、Request Object URI を resolve する request 中に End-Users が fingerprinting されることを防ぐ measures を実装するべきである。

Wallet は、Response URI を通じて意図しない追加情報が開示されることを制限する measures を実装するべきである。例えば、HTTP user agent header を通じた Wallet 関連情報の開示などである。

15.7. Information Security

Wallet providers と Verifiers は、PII の integrity、confidentiality、および一般的な取り扱いを確保するため、運用面・機能面・戦略面で適切な security controls を適用するべきである。さらに、その life cycle 全体を通じて、unauthorized access、破壊、使用、改変、開示、または損失といったリスクに対する protections を検討すべきである。

15.8. Wallet to Verifier Communication

Wallets は、可能な限り最小限の情報のみを送信するべきであり、特に End-User tracking および fingerprinting のリスクを低減するため、request_uri の取得や response_uri への送信の際に、request に使用した software を識別する追加の HTTP headers（例: HTTP libraries やその versions）を送らないようにすべきである。

Wallets は、flow のために明示的に必要であり、かつ End-User により認可されている場合を除き、Verifiers への HTTP requests に personally identifiable information (PII) を含めてはならない。

15.8.1. Establishing Trust in the Request URI

trust framework の中で動作する Wallets は、Request URI が Client Identifier に適切に紐づき、request のために認可されていることを検証するべきである。

信頼できない、または認識できない Request URI endpoints は拒否されるべきであり、または処理を進める前に End-User confirmation を要求すべきである。

15.8.2. Authorization Requests with Request URI

Wallet が、Request URI が特定の Client Identifier に属するかどうかを Wallet が判定できる trust framework の中で動作している場合、Wallet は、Client Identifier により与えられる Verifier の authenticity と authorization、および Request URI がこの Verifier に対応することを検証することが推奨される。そのような link を確立できない場合、Wallet は request を拒否しなければならない。

15.9. Error Responses

error responses は、End-User の data を推測するために利用され得る、センシティブまたは詳細な contextual information を含めることを避けるべきである。

15.9.1. wallet_unavailable Authorization Error Response

Wallet の代わりに別の component が起動された場合、起動された component が wallet_unavailable Authorization Error Response を Verifier に返す前に、End-User は通知され、同意を与えるべきである。

15.9.2. Digital Credential API Error Responses

Digital Credentials API においては、内容に関わらず OpenID4VP protocol error を返すこと自体が、Wallet が request を満たせるかどうかに依存して Wallet に到達することがあり得るため、追加の情報を End-User の underlying Credentials または Wallet について漏えいし得る。たとえば platform implementations は、request を満たせる Wallets だけを選択可能にすることがあり得る。この場合 OpenID4VP protocol error responses は、選択された Wallet によってのみ返され得るため、End-User が request を満たす Credentials を保有していることを漏えいする。他の engagement methods では、Wallet は request を受け取ってから、それを満たせるかどうかを学ぶ。そうした場合に Wallet が何を明らかにするかは、各 Wallet が request をどのように処理するかに依存する。

request が狭いほど、漏えいする情報は増える。

  • 広い範囲の documents により満たせる request は、End-User が大きな documents 集合のうちのいずれかの Credential を持つことのみを漏えいする。
  • 単一の document type に対する request は、End-User がその Credential を保有していることを漏えいする。これがどれほどセンシティブかは当該 Credential に依存する。
  • 単一の trusted authority によってしか満たせない request は、End-User が特定 authority からの Credential を持つことを漏えいし、そこから他の attributes が推測され得る。
  • value matching（Section 6.4.1 で定義）を伴う request は、その claim/attribute の特定値を漏えいする。

Wallet implementations は、Verifier ecosystem の維持とスケールにとっての error detection の価値と、漏えいする情報のバランスを取る必要がある。

Wallet は、platform または Wallet による End-User interaction なしに、いかなる OpenID4VP protocol errors も返すべきではない。error handling において、implementations は OpenID4VP protocol-specific error を返す代わりに flow を cancel（詳細は platform specific）することを選べる。これは、結果を他の platform aborts と区別不能にし、情報漏えいを防ぐ。

Wallet は、value matching を含む request の処理時（同意なしに claims の values を漏えいすることを避けるため）、または issuer selection の処理時（End-User が特定 authority からの Credential を保有することを漏えいすることを避けるため）に、End-User consent を得る前に OpenID4VP protocol errors を返すべきではない。さらに、End-User consent は、Wallet への検知されない反復 requests に対する防御にもなる。

15.10. Establishing Trust in the Issuers

本仕様は、Verifier が期待する Issuers または Issuers を認証する trust frameworks を表現できる extension point を導入する。これらの trust establishment mechanisms がシステム全体のプライバシーに与える含意を理解することが重要である。

一般に、2 種類の mechanisms を区別できる。すなわち、Wallet と Verifier が request を満たすかどうかを確認するために必要な情報を既にすべて持っている self-contained なものと、追加 data を得るために online resolution に依存するものだ。online resolution を必要とする mechanisms は、Credentials の利用状況を profile するのに使われ得る情報を漏えいし得る。

特に、Wallet が一致する presentation を生成する前に data を fetch しなければならない状況では、個々の End-Users に関する情報が外部 parties に露出する可能性がある。

Wallets は、Verifier からの request に含まれる URLs が不慣れである、または信頼できない第三者によりホストされている場合、それらにアクセスするべきではない。プライバシー上のリスクは、そのような URLs を識別子としてのみ扱い、request を受領しても Wallet が実際に取得しないようにすることで低減できる。

trusted authority mechanisms の利用を意図する ecosystems は、選択した mechanisms のプライバシー特性が ecosystem 全体のプライバシー目標と整合していることを保証するべきである。

16. Normative References

省略

17. Informative References

省略

Appendix A. OpenID4VP over the Digital Credentials API

この Appendix は、Digital Credentials API を用いて OpenID4VP を利用する方法を定義する。

ここでいう "Digital Credentials API"（DC API）には、W3C Digital Credentials API（[W3C.Digital_Credentials_API]）に加えて、OS 上の native App Platform 相当（例: Android の Credential Manager）も含まれる。DC API により、Verifier として動作する web site / native app は Credentials の提示（presentation）を要求できる。API 自体は Credential exchange protocol には依存せず、複数の protocol と組み合わせて利用できる。Web Platform は（app platform / OS などの他層と連携しつつ）End-User の許可に基づき、Verifier の Origin と共に request data を End-User が選択した Wallet に送付する。

DC API 上の OpenID4VP は、DC API のメカニズムを利用しつつ、必要に応じて OpenID4VP の advanced security features も活用できるようにする。また、DC API とともに使用してよい OpenID4VP request parameters も定義する。

DC API は、Verifier / Wallet の implementers に対していくつかの利点を提供する。

  • 第一に、URL（特に custom URL scheme）で Wallet を起動することの privacy-preserving な代替である。基盤となる app platform は、End-User が Credential Request と requestor（Verifier）に関する contextual information に基づき request を確認した場合にのみ Wallet を起動する。
  • 第二に、request が fulfilled（または aborted）した後も、End-User との session は初期 context（典型的には web browser tab）で継続するため、End-User 体験が改善される。
  • 第三に、cross-device requests では、OS platform により取り扱われる proximity checks 付きの secure transports の利用が有利である（例: FIDO CTAP 2.2 の hybrid transports）。
  • 最後に、request の一部として、Wallet には user agent により認証された Verifier の Origin 情報が提供され、phishing resistance の観点で重要である。

A.1. Protocol

DC API で OpenID4VP を利用するために、exchange protocol value は次の形式をとる。

  • openid4vp-v<version>-<request-type>

<version> は数値であり、<request-type> は request の種類を明示する。この方式により、Wallet が version と期待される request/response parameters を正確に特定するための 暗黙の parameter matching を行う必要がなくなる。

<version> フィールドには 1 を MUST 使用し、本仕様のこの version と互換であることを示す。

<request-type> は以下の通り MUST である。

  • Appendix A.3.1 の unsigned requests は unsigned
  • Appendix A.3.2.1 の signed requests は signed
  • Appendix A.3.2.2 の multi-signed requests は multisigned

本仕様が定義する exchange protocol values は以下。

  • Unsigned requests: openid4vp-v1-unsigned
  • Signed requests（JWS Compact Serialization）: openid4vp-v1-signed
  • Multi-signed requests（JWS JSON Serialization）: openid4vp-v1-multisigned

A.2. Request

Verifier は、Section 5 で定義される request を DC API に送ってよい。

以下は、OpenID4VP の advanced security features を用いない場合の unsigned OpenID4VP request（non-normative）で、DC API 上に送付できる。

{
  "response_type": "vp_token",
  "response_mode": "dc_api",
  "nonce": "n-0S6_WzA2Mj",
  "client_metadata": {},
  "dcql_query": {}
}

[RFC6749] と Section 5 で定義される Authorization Request parameters のうち、W3C Digital Credentials API 上の OpenID4VP でサポートされるのは次。

  • client_id
  • response_type
  • response_mode
  • nonce
  • client_metadata
  • request
  • transaction_data
  • dcql_query
  • verifier_info

Unsigned request における client_id

Appendix A.3.1 で定義される unsigned requests では、client_id parameter は MUST be omitted。Wallet は、unsigned request 内に client_id が存在しても MUST ignore する。

Client Identifier Prefix 固有 parameters

特定の Client Identifier Prefix が定義する parameters（例: OpenID Federation Client Identifier Prefix の trust_chain）も、W3C Digital Credentials API 上でサポートされる。

Signed request における client_id と response_mode

Appendix A.3.2 で定義される signed requests では、client_id parameter は MUST be present。これは、request signature の検証または client metadata の取得を通じて client を認証する際に、Wallet がどの Client Identifier Prefix / Client Identifier を使うべきかを伝達するためである。

response_mode の値は、以下の MUST を満たす。

  • response が encrypted でない場合: dc_api
  • response が encrypted の場合（Section 8.3 の定義）: dc_api.jwt

Response Mode dc_api は、Wallet が DC API を通じて Authorization Response を送ることを意味する。Response Mode dc_api.jwt では、Wallet は response parameter を含める。この response には、Section 8.3 で定義される「Authorization Response をカプセル化した encrypted JWT」が入る。

DC API 向けの新規 parameter: expected_origins

上記 parameters に加えて、W3C Digital Credentials API 上の OpenID4VP では次の新規 parameter を導入する。

  • expected_origins:
    • Appendix A.3.2 の signed requests を DC API で使用する場合に REQUIRED
    • 非空の string 配列。各 string は request を行う Verifier の Origin を表す。
    • Wallet は、malicious Verifier からの request replay を検知するため、この parameter の値と（実際の）Origin を比較しなければならない。
    • Origin が expected_origins のいずれにも一致しない場合、Wallet は MUST return an error。
      • この error は invalid_request とすることが SHOULD。
    • unsigned requests 用ではないため、unsigned request に含まれていても Wallet は MUST ignore。

request と Origin を Wallet に運ぶ仕組みは platform-specific であり、OpenID4VP over DC API の scope 外である。

追加の request parameters は、DC API 上の OpenID4VP に対して定義・使用してよい。

Wallet は、unrecognized parameters を MUST ignore する。例えば DC API では state parameter が定義されないため、Verifier は response に含まれることを期待できない。

A.3. Signed and Unsigned Requests

本仕様のこの section に準拠する任意の OpenID4VP request は、DC API と併用できる。Verifier を識別・認証する mechanism に応じて、request は signed / unsigned になり得る。本 section は DC API 用の signed / unsigned OpenID4VP requests を定義する。

A.3.1. Unsigned Request

Verifier は、OpenID4VP request parameters を API に渡す request member の members として送ってよい。

A.3.2. Signed Request

Verifier は、例えば Verifier の identification / authentication が要求される場合に、signed request を送ってよい。

signed request は、Wallet が browser が利用する Web PKI だけでなく、1 つ以上の trust framework(s) を用いて Verifier を認証できるようにする。trust framework の例として、EU の eIDAS 規制の文脈で構築される Verifier（RP）管理基盤がある。この場合、Wallet は Verifier の web origin のみに依存できなくなる。web origin は flow の security をさらに強化する目的で使用してよい。外部 trust framework は、例えば Client Identifier を登録済み web origins に map できる。

signed Request Object は、Appendix A.2 の parameters（ただし request は除く）を含んでよい。

Verifier は、signed Requests を JWS Compact Serialization で format することが SHOULD。ただし、後述の use cases のために JWS JSON Serialization（[RFC7515]）を使ってもよい。

A.3.2.1. JWS Compact Serialization

JWS Compact Serialization を用いて request を送る場合、Verifier は 1 つの Trust Framework のみを伝達できる（つまり Verifier は Wallet がサポートする trust frameworks を把握している）。全 request parameters は Section 5 で定義される request object に encode され、JWS object は API call の data element における request claim の値として用いられる。

（non-normative）

{ "request": "eyJhbGciOiJF..." }

以下は、W3C Digital Credentials API 上で JWS Compact Serialization と併用される signed OpenID4VP request の payload 例（non-normative）。

{
  "expected_origins": [
    "https://origin1.example.com",
    "https://origin2.example.com"
  ],
  "client_id": "x509_san_dns:rp.example.com",
  "client_metadata": {
    "jwks": {
      "keys": [
        {
          "kty": "EC",
          "crv": "P-256",
          "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
          "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
          "use": "enc",
          "kid": "1"
        }
      ]
    }
  },
  "response_type": "vp_token",
  "response_mode": "dc_api",
  "nonce": "n-0S6_WzA2Mj",
  "dcql_query": {}
}

A.3.2.2. JWS JSON Serialization

JWS JSON Serialization（[RFC7515]）は、Verifier が複数の Client Identifiers と、それに対応する key material を用いて 同一の request を保護できるようにする。これは、Verifier が異なる trust frameworks に属する Credentials を要求し、それらの trust frameworks の文脈で認証する必要がある use cases に対応する。また、Client Identifier ごとに異なる attestations を付加することも可能にする。

この場合、以下の request parameters を使用するなら、それらは [RFC7515] Section 7.2.1 で定義される signatures array の「該当 signature object の protected header」にのみ存在しなければならない（MUST）。

  • client_id
  • verifier_info
  • Client Identifier Prefix 固有 parameters\ 例: openid_federation Client Identifier Prefix の trust_chain JWS header parameter

それ以外の request parameters は、JWS object の payload element に存在しなければならない（MUST）。

以下は、そのような request の non-normative 例。

{
  "payload": "eyAiaXNzIjogImh0dHBzOi8...NzY4Mzc4MzYiIF0gfQ",
  "signatures": [
    {
      "protected": "eyJhbGciOiAiRVMyNT..MiLCJraWQiOiAiMSJ9XX19fQ",
      "signature": "PFwem0Ajp2Sag...T2z784h8TQqgTR9tXcif0jw"
    },
    {
      "protected": "eyJhbGciOiAiRVMyNTY...tpZCI6ICIxIn1dfX19",
      "signature": "irgtXbJGwE2wN4Lc...2TvUodsE0vaC-NXpB9G39cMXZ9A"
    }
  ]
}

signatures structure 内の各 object は、特定の Client Identifier に固有の parameters と signature を含む。signature は [RFC7515] Section 5.1 に従って計算される。

以下は decoded protected header の content 例（non-normative）。

{
  "alg": "ES256",
  "x5c": [
    "MIICOjCCAeG...djzH7lA==",
    "MIICLTCCAdS...koAmhWVKe"
  ],
  "client_id": "x509_san_dns:rp.example.com"
}

以下は、W3C Digital Credentials API 上で JWS JSON Serialization と併用される signed OpenID4VP request の payload 例（non-normative）。

{
  "expected_origins": [
    "https://origin1.example.com",
    "https://origin2.example.com"
  ],
  "response_type": "vp_token",
  "response_mode": "dc_api",
  "nonce": "n-0S6_WzA2Mj",
  "dcql_query": {},
  "client_metadata": {
    "jwks": {
      "keys": [
        {
          "kty": "EC",
          "crv": "P-256",
          "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
          "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
          "use": "enc",
          "kid": "1"
        }
      ]
    }
  }
}

A.4. Response

各 OpenID4VP Request は、DC API を通じて response が提供されるか、あるいは flow が canceled される。response が提供される場合、response は [W3C.Digital_Credentials_API] で定義される DigitalCredential interface の instance であり、Response Type に対して定義される OpenID4VP Response parameters は data property 内の object として表現される。

protocol error responses は data property 内の object として返される。この object は、error という単一の property を持ち、その値は Section 8.5 で定義される error response code である。Wallet が生成した protocol error であっても、Digital Credentials API request の promise は fulfilled になる点に留意すること。DC API 上の error response 返却に固有の privacy considerations は Section 15.9.2 を参照。

以下は error を含む data object の non-normative 例。

{
  "error": "invalid_request"
}

通常 Client Identifier が提供する security properties は、response を「受領した Origin」に bind することで実現される。

response の audience（例: Key Binding JWT の aud）は Origin でなければならず、origin: を prefix として付ける。例: origin:https://verifier.example.com/。これは signed requests の場合でも同様である。したがって DC API 上の OpenID4VP では、Client Identifier は response の audience として使用されない。

A.5. Security Considerations

OpenID4VP の次の security considerations が適用される。

  • Section 14.1 の Preventing Replay of Verifiable Presentations\ ただし response を Client に bind するために、Client Identifier の代わりに origin を使用する点が異なる。
  • Section 14.4 の End-User Authentication using Credentials
  • Section 14.5 の Encrypting an Unsigned Response
  • Section 14.6 の TLS Requirements
  • Section 14.8 の Always Use the Full Client Identifier（signed requests に対して）
  • Section 14.9 の Security Checks on the Returned Credentials and Presentations
  • Section 15.4.1 の DCQL Value Matching

A.6. Privacy Considerations

OpenID4VP の次の privacy considerations が適用される。

  • Section 15.4 の Selective Disclosure
  • Section 15.10 の Issuers の trust を確立する mechanisms の privacy implications

Appendix B. Credential Format Specific Parameters and Rules

OpenID for Verifiable Presentations は Credential Format agnostic である。すなわち、任意の Credential Format で Presentations を要求・受領できるように設計されている。本 Appendix は、既知のいくつかの Credential Formats に対して、Credential Format specific parameters と rules を定義する。本仕様で言及されない Credential Formats については、他の specifications または deployments が独自に定義できる。

B.1. W3C Verifiable Credentials

以下の sections は、[VC_DATA] に準拠する W3C Verifiable Credentials と、そのような Credentials の W3C Verifiable Presentations に対する format-specific parameters / rules を定義する。

Credential Query において require_cryptographic_holder_binding が true に set されている場合、Wallet は Verifiable Credential の Verifiable Presentation を返さなければならない（MUST）。そうでなければ、Holder Binding なしの Verifiable Credential を返さなければならない（MUST）。

B.1.1. Parameters in the meta parameter in Credential Query

Section 6.1 の Credential Query で定義される meta parameter における W3C Verifiable Credentials specific parameter は次の通り。

type_values

  • REQUIRED
  • non-empty array of string arrays
  • type_values の各要素は non-empty array であり、Verifier が Presentation 内で受け入れる fully expanded types（IRIs）を指定する。これは Verifiable Credential に @context を適用した後の type を想定する。

type value がいかなる @context にも定義されない場合、その値は unchanged のままであり、JSON-LD processing 後も relative IRI のままとなる。このため、そのような場合は JSON-LD processing を skip してもよく（MAY）、relative IRI を fully expanded type とみなす（@context を適用しても値が変化しないため）。実装は、JSON-LD processing で得られる結果と等価である限り、fully expanded types を得るための別の mechanisms を用いてよい（MAY）。

type_values の各 top-level array は、Verifiable Credential の type values に対して照合する 代替案（OR）を表す。各 inner array は、Verifiable Credential の type property に含まれる fully expanded types の中に、（順序や追加 types の有無に関わらず）必ず存在しなければならない types の集合を表す（MUST）。

以下は DCQL query における type_values の non-normative 例。

{
  "type_values": [
    [
      "https://www.w3.org/2018/credentials#VerifiableCredential",
      "https://example.org/examples#AlumniCredential",
      "https://example.org/examples#BachelorDegree"
    ],
    [
      "https://www.w3.org/2018/credentials#VerifiableCredential",
      "https://example.org/examples#UniversityDegreeCredential"
    ],
    [
      "IdentityCredential"
    ]
  ]
}

上記 type_values DCQL query に match する W3C Verifiable Credential の non-normative 例（可読性のため他の claims は省略）。

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": ["VerifiableCredential", "UniversityDegreeCredential"]
}

別の match 例（non-normative）。

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": ["VerifiableCredential", "BachelorDegree", "AlumniCredential"]
}

さらに別の match 例（non-normative）。

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "type": ["VerifiableCredential", "IdentityCredential"]
}

B.1.2. Claims Matching

Section 6.1 の Credential Query で定義される claims_path parameter は、Verifier が Presentation で受け取りたい claims を指定するために用いる。W3C Verifiable Credentials の文脈では、claims_path は常に Verifiable Credential の root に対して match する（Verifiable Presentation ではない）。例は後続の subsections に示される。

B.1.3. Formats and Examples

B.1.3.1. VC signed as a JWT, not using JSON-LD

この section は、[VC_DATA] に準拠し、JWS で署名され、JSON-LD を使用しない Credential の提示（presentation）を例示する。

B.1.3.1.1. Format Identifier and Cipher Suites

Credential Format Identifier は jwt_vc_json であり、[VC_DATA] 準拠の W3C Verifiable Credential またはその Verifiable Presentation を request するために用いる。

Cipher suites は、IANA JOSE Algorithms Registry で定義される algorithm names を使用するべきである。

B.1.3.1.2. Example Credential

本 section 全体で使用する JWT-based W3C Verifiable Credential の payload 例（non-normative）。

{
  "iss": "https://example.gov/issuers/565049",
  "nbf": 1262304000,
  "jti": "http://example.gov/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": [
      "VerifiableCredential",
      "IDCredential"
    ],
    "credentialSubject": {
      "given_name": "Max",
      "family_name": "Mustermann",
      "birthdate": "1998-01-11",
      "address": {
        "street_address": "Sandanger 25",
        "locality": "Musterstadt",
        "postal_code": "123456",
        "country": "DE"
      }
    }
  }
}
B.1.3.1.3. Metadata

Verifier metadata または Wallet metadata の vp_formats_supported parameter は、Credential Format Identifier を key として持たなければならず（MUST）、value は次の name/value pair を持つ object でなければならない（MUST）。

  • alg_values: OPTIONAL\ JWT-secured W3C Verifiable Credential または W3C Verifiable Presentation に対してサポートされる cryptographic algorithms の identifiers を含む non-empty array。存在する場合、提示される Verifiable Credential / Verifiable Presentation の alg JOSE header（[RFC7515]）は配列内のいずれかに一致しなければならない（MUST）。

W3C Verifiable Presentation の提示 request における client_metadata request parameter の non-normative 例。

{
  "vp_formats_supported": {
    "jwt_vc_json": {
      "alg_values": ["ES256", "ES384"]
    }
  }
}
B.1.3.1.4. Presentation Request

提示される Credential に対する要件は dcql_query parameter で伝達される。以下は non-normative 例。

{
  "credentials": [
    {
      "id": "example_jwt_vc",
      "format": "jwt_vc_json",
      "meta": {
        "type_values": [["IDCredential"]]
      },
      "claims": [
        { "path": ["credentialSubject", "family_name"] },
        { "path": ["credentialSubject", "given_name"] }
      ]
    }
  ]
}
B.1.3.1.5. Presentation Response

Verifiable Presentation の nonce と aud claims には次が適用される。

  • nonce claim は Authorization Request の nonce の値でなければならない（MUST）。
  • aud claim は Client Identifier の値でなければならない（MUST）。ただし DC API 上の requests の場合は例外で、Appendix A.4 の通り origin: を prefix とする Origin でなければならない（MUST）。

response で提供される VP Token の non-normative 例（表示のため短縮）。

{
  "example_jwt_vc": ["eY...QMA"]
}

直前の例の VP Token 内の Verifiable Presentation payload の non-normative 例。

{
  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "aud": "x509_san_dns:client.example.org",
  "nbf": 1541493724,
  "iat": 1541493724,
  "exp": 1573029723,
  "nonce": "n-0S6_WzA2Mj",
  "vp": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1"
    ],
    "type": [
      "VerifiablePresentation"
    ],
    "verifiableCredential": [
      "eyJhb...ssw5c"
    ]
  }
}

B.1.3.2. LDP VCs

この section は、[VC_DATA] に準拠し、JSON-LD を用い、Data Integrity で保護される Credential の提示を例示する。

B.1.3.2.1. Format Identifier and Cipher Suites

Credential Format Identifier は ldp_vc であり、[VC_DATA] 準拠の W3C Verifiable Credential またはその Verifiable Presentation を request するために用いる。

Cipher suites は、Verifiable Credential Extensions で定義される Data Integrity compatible securing mechanisms を使用するべきである。

B.1.3.2.2. Example Credential

本 section 全体で使用する Verifiable Credential payload の non-normative 例。

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    "https://w3id.org/security/data-integrity/v2"
  ],
  "id": "https://example.com/credentials/1872",
  "type": [
    "VerifiableCredential",
    "IDCredential"
  ],
  "issuer": {
    "id": "did:example:issuer"
  },
  "issuanceDate": "2025-03-19T00:00:00Z",
  "credentialSubject": {
    "given_name": "Max",
    "family_name": "Mustermann",
    "birthdate": "1998-01-11",
    "address": {
      "street_address": "Sandanger 25",
      "locality": "Musterstadt",
      "postal_code": "123456",
      "country": "DE"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2025-03-19T15:30:15Z",
    "proofValue": "z5C5b...EtszK",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:example:issuer#keys-1"
  }
}
B.1.3.2.3. Metadata

Verifier metadata または Wallet metadata の vp_formats_supported parameter は、Credential Format Identifier を key として持たなければならず（MUST）、value は次の name/value pairs を持つ object でなければならない（MUST）。

  • proof_type_values: OPTIONAL\ Data Integrity で保護される W3C Verifiable Presentation / W3C Verifiable Credential に対してサポートされる proof types の identifiers を含む non-empty array。存在する場合、提示される Verifiable Credential / Verifiable Presentation の proof type parameter（[VC_DATA]）は配列内のいずれかに一致しなければならない（MUST）。
  • cryptosuite_values: OPTIONAL\ proof_type_values に列挙された algorithms のいずれかでサポートされる crypto suites の identifiers を含む non-empty array。proof_type_values のある algorithm が複数 crypto suites をサポートする場合に cryptosuite_values を用いてよい（MAY）。存在する場合、提示される Verifiable Credential / Verifiable Presentation の proof cryptosuite parameter（[VC_DATA_INTEGRITY]）は配列内のいずれかに一致しなければならない（MUST）。

W3C Verifiable Presentation の提示 request における client_metadata request parameter の non-normative 例。

{
  "vp_formats_supported": {
    "ldp_vc": {
      "proof_type_values": [
        "DataIntegrityProof",
        "Ed25519Signature2020"
      ],
      "cryptosuite_values": [
        "ecdsa-rdfc-2019",
        "ecdsa-sd-2023",
        "ecdsa-jcs-2019",
        "bbs-2023"
      ]
    }
  }
}
B.1.3.2.4. Presentation Request

提示される Credential に対する要件は dcql_query parameter で伝達される。以下は non-normative 例。

{
  "credentials": [
    {
      "id": "example_ldp_vc",
      "format": "ldp_vc",
      "meta": {
        "type_values": [["IDCredential"]]
      },
      "claims": [
        { "path": ["credentialSubject", "family_name"] },
        { "path": ["credentialSubject", "given_name"] },
        { "path": ["credentialSubject", "birthdate"] },
        { "path": ["credentialSubject", "address", "street_address"] },
        { "path": ["credentialSubject", "address", "locality"] },
        { "path": ["credentialSubject", "address", "postal_code"] },
        { "path": ["credentialSubject", "address", "country"] }
      ]
    }
  ]
}
B.1.3.2.5. Presentation Response

Verifiable Presentation の proof object 内の challenge と domain claims には次が適用される。

  • challenge claim は Authorization Request の nonce の値でなければならない（MUST）。
  • domain claim は Client Identifier の値でなければならない（MUST）。ただし DC API 上の requests の場合は例外で、Appendix A.4 の通り origin: を prefix とする Origin でなければならない（MUST）。

vp_token parameter に含まれる Verifiable Presentation の non-normative 例。

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/data-integrity/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1",
        "https://w3id.org/security/data-integrity/v2"
      ],
      "id": "https://example.com/credentials/1872",
      "type": [
        "VerifiableCredential",
        "IDCredential"
      ],
      "issuer": {
        "id": "did:example:issuer"
      },
      "issuanceDate": "2025-03-19T00:00:00Z",
      "credentialSubject": {
        "given_name": "Max",
        "family_name": "Mustermann",
        "birthdate": "1998-01-11",
        "address": {
          "street_address": "Sandanger 25",
          "locality": "Musterstadt",
          "postal_code": "123456",
          "country": "DE"
        }
      },
      "proof": {
        "type": "DataIntegrityProof",
        "cryptosuite": "eddsa-rdfc-2022",
        "created": "2025-03-19T15:30:15Z",
        "proofValue": "z5C5b...EtszK",
        "proofPurpose": "assertionMethod",
        "verificationMethod": "did:example:issuer#keys-1"
      }
    }
  ],
  "id": "ebc6f1c2",
  "holder": "did:example:holder",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2025-04-04T10:12:15Z",
    "challenge": "n-0S6_WzA2Mj",
    "domain": "x509_san_dns:client.example.org",
    "proofValue": "z5s8c...AD3a9d",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:holder#key-1"
  }
}

B.2. Mobile Documents or mdocs (ISO/IEC 18013 and ISO/IEC 23220 series)

ISO/IEC 18013-5:2021 [ISO.18013-5] は、mobile document（mdoc）形式における mobile driving license（mDL）Credential を定義する。ISO/IEC 18013-5:2021 は mDL に特化しているが、この Credential format は任意の種類の Credential（または mdoc document types）に利用できる。ISO/IEC 23220 series は、他の document types 向けに仕様を profile しやすくするために、ISO/IEC 18013-5:2021 から document types 間で共通な components を抽出したものである。

core data structures は ISO/IEC 18013-5:2021 [ISO.18013-5]、ISO/IEC 23220-2 [ISO.23220-2]、ISO/IEC 23220-4 [ISO.23220-4] で共有され、CBOR で encode され、COSE_Sign1 により保護される。

mdoc format の Credentials に対する Credential Format Identifier は mso_mdoc である。

B.2.1. Transaction Data

各 transaction data type が、処理済み transaction data を返すために使う data element（NameSpace, DataElementIdentifier, DataElementValue）を定義することが RECOMMENDED。加えて、processing rules（適用する hash function を含みうる）と、期待される resulting structure を指定することも RECOMMENDED。

一部の document types は、transaction data（Section 8.4）を mdoc authentication（[ISO.18013-5] の DeviceSigned data structure の一部）で保護することをサポートする。その場合、これら document types の仕様は、どの transaction data types がサポートされるかを含み、issuer は KeyAuthorizations に関連 data elements を含める。Wallet が、data element が unauthorized な transaction_data type を含む request を受け取った場合、Wallet は unsupported transaction data type として request を MUST reject する。

B.2.2. Metadata

Verifier metadata / Wallet metadata の vp_formats_supported parameter は、Credential Format Identifier を key として持たなければならず（MUST）、value は以下の name/value pairs からなる object でなければならない（MUST）。

issuerauth_alg_values

  • OPTIONAL
  • cryptographic algorithm identifiers を含む non-empty array
  • Credential は、以下のいずれかが true なら、この parameter が表現する requirement(s) を満たすとみなされなければならない（MUST be considered to fulfill）。
    1. array 内の値が IssuerAuth COSE header の alg 値に一致する
    2. array 内の値が [I-D.ietf-jose-fully-specified-algorithms] に従う fully specified algorithm であり、IssuerAuth COSE header の alg 値と COSE structure の署名鍵が用いる curve の組み合わせが、その fully specified algorithm が識別する algorithm+curve の組み合わせに一致する

例として、IssuerAuth structure が alg header に -7（[IANA.COSE] における ECDSA with SHA-256）を持ち、P-256 key で署名されている場合、issuerauth_alg_values の要素 -7 および -9（[I-D.ietf-jose-fully-specified-algorithms] における P-256 curve + SHA-256 を用いる ECDSA）に match する。

deviceauth_alg_values

  • OPTIONAL
  • cryptographic algorithm identifiers を含む non-empty array
  • Credential は、以下のいずれかが true なら、この parameter が表現する requirement(s) を満たすとみなされなければならない（MUST be considered to fulfill）。
    1. array 内の値が DeviceSignature または DeviceMac COSE header の alg 値に一致する
    2. array 内の値が [I-D.ietf-jose-fully-specified-algorithms] に従う fully-specified algorithm であり、DeviceSignature COSE header の alg 値と COSE structure の署名鍵が用いる curve の組み合わせが、その fully-specified algorithm が識別する algorithm+curve の組み合わせに一致する
    3. DeviceMac COSE header の alg が HMAC 256/256（[ISO.18013-5] Section 9.1.3.5）であり、device key の curve（[ISO.18013-5] Table 22）が、以下の表で定義される identifiers によって array 内の値に match する

Table 2: Mapping of curves to alg identifiers used for the HMAC 256/256 case

Algorithm Name Algorithm Value
HMAC 256/256 using ECDH with Curve P-256 -65537
HMAC 256/256 using ECDH with Curve P-384 -65538
HMAC 256/256 using ECDH with Curve P-521 -65539
HMAC 256/256 using ECDH with X25519 -65540
HMAC 256/256 using ECDH with X448 -65541
HMAC 256/256 using ECDH with brainpoolP256r1 -65542
HMAC 256/256 using ECDH with brainpoolP320r1 -65543
HMAC 256/256 using ECDH with brainpoolP384r1 -65544
HMAC 256/256 using ECDH with brainpoolP512r1 -65545

Note: これらは本仕様において、この parameter 内での private use のために OpenID4VP の中で指定されており、将来 IANA で registration されることで superseded される可能性がある。

deviceauth_alg_values の non-normative 例

以下は、[ISO.18013-5] Section 9.1.3.5 に従い、MAC key が P-256 curve の鍵を用いた ECDH により確立される HMAC 256/256 の DeviceMac を verifier がサポートすることを示す。

{
  "deviceauth_alg_values": [-65537]
}

以下は、上記の HMAC 256/256 DeviceMac（P-256 ECDH）に加えて、P-256 curve を用いる ECDSA の DeviceSignature も verifier がサポートすることを示す。

{
  "deviceauth_alg_values": [-65537, -9]
}

ISO/IEC 18013-5 mDOC の提示 request における client_metadata request parameter の non-normative 例。

{
  "vp_formats_supported": {
    "mso_mdoc": {
      "issuerauth_alg_values": [-9, -50],
      "deviceauth_alg_values": [-9, -50]
    }
  }
}

B.2.3. Parameter in the meta parameter in Credential Query

Section 6.1 の Credential Query における meta parameter の ISO mdoc specific parameter は次の通り。

doctype_value

  • REQUIRED
  • requested Verifiable Credential の doctype に許容される値を指定する string
  • [ISO.18013-5] で定義される valid doctype identifier でなければならない（MUST）

B.2.4. Parameter in the Claims Query

Section 6.3 の Claims Query で使用する ISO mdoc specific parameters は次の通り。

intent_to_retain

  • OPTIONAL
  • boolean
  • [ISO.18013-5] Section 8.3.2.1.2.1 で定義される IntentToRetain 変数と等価

B.2.5. Presentation Response

mdoc format を用いる DCQL query の例は Appendix D に示される。以下は response における VP Token の non-normative 例。

{
  "my_credential": ["<base64url-encoded DeviceResponse>"]
}

VP Token は、ISO/IEC 18013-5 [ISO.18013-5] または ISO/IEC 23220-4 [ISO.23220-4] で定義される、base64url-encoded DeviceResponse CBOR structure を含む。本質的に、DeviceResponse CBOR structure は、OpenID4VP-specific Handover CBOR structure を含む SessionTranscript CBOR structure に対する signature または MAC を含む。

B.2.6. Handover and SessionTranscript Definitions

B.2.6.1. Invocation via Redirects

presentation request が redirects により起動される場合、[ISO.18013-5] Section 9.1.5.1 で定義される SessionTranscript CBOR structure を、以下の変更を加えて使用しなければならない（MUST）。

  • DeviceEngagementBytes MUST be null
  • EReaderKeyBytes MUST be null
  • Handover MUST be the OpenID4VPHandover CBOR structure（以下で定義）
OpenID4VPHandover = [
  "OpenID4VPHandover", ; A fixed identifier for this handover type
  OpenID4VPHandoverInfoHash ; A cryptographic hash of OpenID4VPHandoverInfo
]

; Contains the sha-256 hash of OpenID4VPHandoverInfoBytes
OpenID4VPHandoverInfoHash = bstr

; Contains the bytes of OpenID4VPHandoverInfo encoded as CBOR
OpenID4VPHandoverInfoBytes = bstr .cbor OpenID4VPHandoverInfo

OpenID4VPHandoverInfo = [
  clientId,
  nonce,
  jwkThumbprint,
  responseUri
] ; Array containing handover parameters

clientId = tstr
nonce = tstr
jwkThumbprint = bstr
responseUri = tstr
OpenID4VPHandover の要素
  • 第1要素は string "OpenID4VPHandover" でなければならない（MUST）。誤解釈や混同を防ぐための unique identifier として機能する。
  • 第2要素は Byte String でなければならず（MUST）、CBOR encode された OpenID4VPHandoverInfo の bytes の sha-256 hash を含む。
OpenID4VPHandoverInfo の要素
  • 第1要素は client_id request parameter でなければならない（MUST）。該当する場合、Client Identifier Prefix も含む。
  • 第2要素は nonce request parameter の値でなければならない（MUST）。
  • response が encrypted の場合（例: direct_post.jwt）、第3要素は Verifier が response 暗号化に使う public key の JWK SHA-256 Thumbprint（[RFC7638]）を Byte String として encode したものでなければならない（MUST）。それ以外の場合、第3要素は null でなければならない（MUST）。重要性の説明は Appendix B.2.6.2 を参照。
  • 第4要素は、Response Mode に応じて、redirect_uri または response_uri request parameter のいずれかでなければならない（MUST）（どちらが present かで決まる）。

特に断りがない限り、上記で参照される client_id, nonce, redirect_uri, response_uri の値は以下から取得しなければならない（MUST）。

  • request が unsigned の場合: Authorization Request の query parameters
  • request が signed の場合: signed Request Object
JWK Thumbprint 計算用 input JWK の non-normative 例
{
  "kty": "EC",
  "crv": "P-256",
  "x": "DxiH5Q4Yx3UrukE2lWCErq8N8bqC9CHLLrAwLz5BmE0",
  "y": "XtLM4-3h5o3HUH0MHVJV0kyq0iBlrBwlh8qEDMZ4-Pc",
  "use": "enc",
  "alg": "ECDH-ES",
  "kid": "1"
}
OpenID4VPHandoverInfo の non-normative 例

Hex:

847818783530395f73616e5f646e733a6578616d706c652e636f6d782b6578633767
426b786a7831726463397564527276654b7653734a4971383061766c58654c486847
7771744158204283ec927ae0f208daaa2d026a814f2b22dca52cf85ffa8f3f8626c6
bd669047781c68747470733a2f2f6578616d706c652e636f6d2f726573706f6e7365

CBOR diagnostic:

84                                 # array(4)
  78 18                            #   string(24)
    783530395f73616e5f646e733a6578 #     "x509_san_dns:ex"
    616d706c652e636f6d             #     "ample.com"
  78 2b                            #   string(43)
    6578633767426b786a783172646339 #     "exc7gBkxjx1rdc9"
    7564527276654b7653734a49713830 #     "udRrveKvSsJIq80"
    61766c58654c48684777717441     #     "avlXeLHhGwqtA"
  58 20                            #   bytes(32)
    4283ec927ae0f208daaa2d026a814f #     "B\x83ì\x92zàò\x08Úª-\x02j\x81O"
    2b22dca52cf85ffa8f3f8626c6bd66 #     "+"Ü¥,ø_ú\x8f?\x86&ƽf"
    9047                           #     "\x90G"
  78 1c                            #   string(28)
    68747470733a2f2f6578616d706c65 #     "https://example"
    2e636f6d2f726573706f6e7365     #     ".com/response"
OpenID4VPHandover の non-normative 例

Hex:

82714f70656e494434565048616e646f7665725820048bc053c00442af9b8eed494c
efdd9d95240d254b046b11b68013722aad38ac

CBOR diagnostic:

82                                 # array(2)
  71                               #   string(17)
    4f70656e494434565048616e646f76 #     "OpenID4VPHandov"
    6572                           #     "er"
  58 20                            #   bytes(32)
    048bc053c00442af9b8eed494cefdd #     "\x04\x8bÀSÀ\x04B¯\x9b\x8eíILïÝ"
    9d95240d254b046b11b68013722aad #     "\x9d\x95$\x0d%K\x04k\x11¶\x80\x13r*­"
    38ac                           #     "8¬"
SessionTranscript の non-normative 例

Hex:

83f6f682714f70656e494434565048616e646f7665725820048bc053c00442af9b8e
ed494cefdd9d95240d254b046b11b68013722aad38ac

CBOR diagnostic:

83                                 # array(3)
  f6                               #   null
  f6                               #   null
  82                               #   array(2)
    71                             #     string(17)
      4f70656e494434565048616e646f #       "OpenID4VPHando"
      766572                       #       "ver"
    58 20                          #     bytes(32)
      048bc053c00442af9b8eed494cef #       "\x04\x8bÀSÀ\x04B¯\x9b\x8eíILï"
      dd9d95240d254b046b11b6801372 #       "Ý\x9d\x95$\x0d%K\x04k\x11¶\x80\x13r"
      2aad38ac                     #       "*­8¬"

B.2.6.2. Invocation via the Digital Credentials API

presentation request が Digital Credentials API により起動される場合、[ISO.18013-5] Section 9.1.5.1 で定義される SessionTranscript CBOR structure を、以下の変更を加えて使用しなければならない（MUST）。

  • DeviceEngagementBytes MUST be null
  • EReaderKeyBytes MUST be null
  • Handover MUST be the OpenID4VPDCAPIHandover CBOR structure（以下で定義）

Note: 以下の section には CDDL（Concise Data Definition Language）の定義が含まれる。[RFC8610] を参照。bstr は CBOR の major type 2 の Byte String、tstr は CBOR の major type 3 の Text String（utf-8 encode）を指す（[RFC8949] Section 3.1）。

OpenID4VPDCAPIHandover = [
  "OpenID4VPDCAPIHandover", ; A fixed identifier for this handover type
  OpenID4VPDCAPIHandoverInfoHash ; A cryptographic hash of OpenID4VPDCAPIHandoverInfo
]

; Contains the sha-256 hash of OpenID4VPDCAPIHandoverInfoBytes
OpenID4VPDCAPIHandoverInfoHash = bstr

; Contains the bytes of OpenID4VPDCAPIHandoverInfo encoded as CBOR
OpenID4VPDCAPIHandoverInfoBytes = bstr .cbor OpenID4VPDCAPIHandoverInfo

OpenID4VPDCAPIHandoverInfo = [
  origin,
  nonce,
  jwkThumbprint
] ; Array containing handover parameters

origin = tstr
nonce = tstr
jwkThumbprint = bstr
OpenID4VPDCAPIHandover の要素
  • 第1要素は string "OpenID4VPDCAPIHandover" でなければならない（MUST）。誤解釈や混同を防ぐための unique identifier として機能する。
  • 第2要素は Byte String でなければならず（MUST）、CBOR encode された OpenID4VPDCAPIHandoverInfo の bytes の sha-256 hash を含む。
OpenID4VPDCAPIHandoverInfo の要素
  • 第1要素は Appendix A.2 で述べた request の Origin を表す string でなければならない（MUST）。origin: prefix を付与してはならない（MUST NOT）。
  • 第2要素は nonce request parameter の値でなければならない（MUST）。
  • Response Mode が dc_api.jwt の場合、第3要素は response 暗号化に使う Verifier public key の JWK SHA-256 Thumbprint（[RFC7638]）を Byte String として encode したものでなければならない（MUST）。
    • Response Mode が dc_api の場合、第3要素は null でなければならない（MUST）。
    • unsigned requests において SessionTranscript に JWK Thumbprint を含めることにより、Verifier は「第三者によって response が再暗号化されたかどうか」を検知でき、結果として sensitive information の漏洩につながりうる状況を検出可能になる。この仕組み自体は攻撃を防止しないが、検知可能にして response の confidentiality を助ける。
JWK Thumbprint 計算用 input JWK の non-normative 例
{
  "kty": "EC",
  "crv": "P-256",
  "x": "DxiH5Q4Yx3UrukE2lWCErq8N8bqC9CHLLrAwLz5BmE0",
  "y": "XtLM4-3h5o3HUH0MHVJV0kyq0iBlrBwlh8qEDMZ4-Pc",
  "use": "enc",
  "alg": "ECDH-ES",
  "kid": "1"
}
OpenID4VPDCAPIHandoverInfo の non-normative 例

Hex:

837368747470733a2f2f6578616d706c652e636f6d782b6578633767426b786a7831
726463397564527276654b7653734a4971383061766c58654c486847777174415820
4283ec927ae0f208daaa2d026a814f2b22dca52cf85ffa8f3f8626c6bd669047

CBOR diagnostic:

83                                 # array(3)
  73                               #   string(19)
    68747470733a2f2f6578616d706c65 #     "https://example"
    2e636f6d                       #     ".com"
  78 2b                            #   string(43)
    6578633767426b786a783172646339 #     "exc7gBkxjx1rdc9"
    7564527276654b7653734a49713830 #     "udRrveKvSsJIq80"
    61766c58654c48684777717441     #     "avlXeLHhGwqtA"
  58 20                            #   bytes(32)
    4283ec927ae0f208daaa2d026a814f #     "B\x83ì\x92zàò\x08Úª-\x02j\x81O"
    2b22dca52cf85ffa8f3f8626c6bd66 #     "+"Ü¥,ø_ú\x8f?\x86&ƽf"
    9047                           #     "\x90G"
OpenID4VPDCAPIHandover の non-normative 例

Hex:

82764f70656e4944345650444341504948616e646f7665725820fbece366f4212f97
62c74cfdbf83b8c69e371d5d68cea09cb4c48ca6daab761a

CBOR diagnostic:

82                                 # array(2)
  76                               #   string(22)
    4f70656e4944345650444341504948 #     "OpenID4VPDCAPIH"
    616e646f766572                 #     "andover"
  58 20                            #   bytes(32)
    fbece366f4212f9762c74cfdbf83b8 #     "ûìãfô!/\x97bÇLý¿\x83¸"
    c69e371d5d68cea09cb4c48ca6daab #     "Æ\x9e7\x1d]hÎ\xa0\x9c´Ä\x8c¦Ú«"
    761a                           #     "v\x1a"
SessionTranscript の non-normative 例

Hex:

83f6f682764f70656e4944345650444341504948616e646f7665725820fbece366f4
212f9762c74cfdbf83b8c69e371d5d68cea09cb4c48ca6daab761a

CBOR diagnostic:

83                                 # array(3)
  f6                               #   null
  f6                               #   null
  82                               #   array(2)
    76                             #     string(22)
      4f70656e49443456504443415049 #       "OpenID4VPDCAPI"
      48616e646f766572             #       "Handover"
    58 20                          #     bytes(32)
      fbece366f4212f9762c74cfdbf83 #       "ûìãfô!/\x97bÇLý¿\x83"
      b8c69e371d5d68cea09cb4c48ca6 #       "¸Æ\x9e7\x1d]hÎ\xa0\x9c´Ä\x8c¦"
      daab761a                     #       "Ú«v\x1a"

B.3. IETF SD-JWT VC

この section は、[I-D.ietf-oauth-sd-jwt-vc] に準拠する Credentials を、本仕様を用いて Verifier に提示する方法を定義する。

Credential Query において require_cryptographic_holder_binding が true の場合、Wallet は Verifiable Presentation として、Key Binding JWT を伴う SD-JWT（SD-JWT+KB）を返さなければならない（MUST）。Holder Binding をサポートしない SD-JWT（すなわち cnf Claim を持たないもの）は、この場合返却できない。require_cryptographic_holder_binding が false の場合、Key Binding JWT を伴わない SD-JWT を返してよい（MAY）。

B.3.1. Format Identifier

Credential Format Identifier は dc+sd-jwt である。

B.3.2. Example Credential

本 section 全体で使用する IETF SD-JWT VC の unsecured payload の non-normative 例。

{
  "vct": "https://credentials.example.com/identity_credential",
  "given_name": "John",
  "family_name": "Doe",
  "birthdate": "1940-01-01"
}

上記 unsecured payload を用いた、selectively disclosable な claims を含む IETF SD-JWT VC の non-normative 例。

{
  "_sd": [
    "3oUCnaKt7wqDKuyh-LgQozzfhgb8gO5Ni-RCWsWW2vA",
    "8z8z9X9jUtb99gjejCwFAGz4aqlHf-sCqQ6eM_qmpUQ",
    "Cxq4872UXXngGULT_kl8fdwVFkyK6AJfPZLy7L5_0kI",
    "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
    "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4",
    "sFcViHN-JG3eTUyBmU4fkwusy5I1SLBhe1jNvKxP5xM",
    "tiTngp9_jhC389UP8_k67MXqoSfiHq3iK6o9un4we_Y",
    "xsKkGJXD1-e3I9zj0YyKNv-lU5YqhsEAF9NhOr8xga4"
  ],
  "iss": "https://example.com/issuer",
  "iat": 1683000000,
  "exp": 1883000000,
  "vct": "https://credentials.example.com/identity_credential",
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

上記例の claims に対応する disclosures は以下。

Claim given_name

  • SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
  • Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o
biJd
  • Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]

Claim family_name

  • SHA-256 Hash: TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
  • Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
ZSJd
  • Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]

Claim birthdate

  • SHA-256 Hash: tiTngp9_jhC389UP8_k67MXqoSfiHq3iK6o9un4we_Y
  • Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTQw
LTAxLTAxIl0
  • Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1940-01-01"]

B.3.3. Transaction Data

各 transaction data type が、処理済み transaction data を返すために、Key Binding JWT 内で使用する top-level claim parameter を定義することが RECOMMENDED。加えて、processing rules（適用する hash function を含みうる）と、期待される resulting structure を指定することも RECOMMENDED。

transaction data mechanism は、Cryptographic Holder Binding を持つ SD-JWT VC を必要とする。Wallet は、require_cryptographic_holder_binding が false に set された transaction data types を含む request を MUST reject する。

B.3.3.1. A Profile of Transaction Data in SD-JWT VC

transaction data type specification に含められる profile の 1 つは次の通り。

transaction_data request parameter は、Section 5.1 の type と credential_ids に加えて次の parameter を含む。

  • transaction_data_hashes_alg:
    • OPTIONAL
    • non-empty array of strings（hash algorithm identifier）
    • transaction_data_hashes response parameter の hashes を計算するために、これらのうち 1 つを MUST 使用する
    • identifier の値は、IANA "Named Information Hash Algorithm" registry（[IANA.Hash.Algorithms]）の "Hash Name String" column にある hash algorithm value、または本仕様の別 specification / profile で定義された値でなければならない（MUST）
    • present でなければ default は sha-256（MUST）
    • interoperability を促進するため、実装は sha-256 をサポートしなければならない（MUST）

response の Key Binding JWT は次の top-level parameters を含む。

  • transaction_data_hashes:
    • non-empty array of strings
    • 各要素は base64url-encoded hash
    • 各 hash は transaction_data request parameter 内で受け取った string に対して hash function を適用して計算される（hash 前に base64url decode は行わない）
    • 各 hash は対応する transaction data object の integrity を保証し、対応付ける
    • request で transaction_data_hashes_alg が指定された場合、hash function はその値のいずれかでなければならない（MUST）
    • request で未指定の場合、hash function は sha-256 でなければならない（MUST）
  • transaction_data_hashes_alg:
    • request の transaction_data にこの parameter が present だった場合に REQUIRED
    • transaction_data_hashes の計算に用いた hash algorithm identifier を表す string

B.3.4. Metadata

Verifier metadata / Wallet metadata の vp_formats_supported parameter は Credential Format Identifier を key として持たなければならず（MUST）、value は以下の name/value pairs からなる object でなければならない（MUST）。

  • sd-jwt_alg_values: OPTIONAL\ SD-JWT の Issuer-signed JWT に対してサポートされる cryptographic algorithms の fully-specified identifiers（[I-D.ietf-jose-fully-specified-algorithms]）を含む non-empty array
  • kb-jwt_alg_values: OPTIONAL\ Key Binding JWT（KB-JWT）に対してサポートされる cryptographic algorithms の fully-specified identifiers（同上）を含む non-empty array

IETF SD-JWT VC の提示 request における client_metadata request parameter の non-normative 例。

{
  "vp_formats_supported": {
    "dc+sd-jwt": {
      "sd-jwt_alg_values": ["ES256", "ES384"],
      "kb-jwt_alg_values": ["ES256", "ES384"]
    }
  }
}

B.3.5. Parameter in the meta parameter in Credential Query

Section 6.1 の Credential Query における meta parameter の SD-JWT VC specific parameter は次の通り。

vct_values

  • REQUIRED
  • requested Verifiable Credential の type に許容される値を指定する non-empty array of strings
  • array 内の全要素は [I-D.ietf-oauth-sd-jwt-vc] で定義される valid type identifiers でなければならない（MUST）
  • Wallet は、[I-D.ietf-oauth-sd-jwt-vc] で定義される inheritance logic に従い、指定 types のいずれかを継承する Credentials を返してよい（MAY）

B.3.6. Presentation Response

SD-JWT VC format を用いる DCQL query の non-normative 例は Section 7.4 に示され、対応する response は Section 8.1.1 に示される。追加の例は Appendix D に示される。

Key Binding JWT 内の nonce と aud claims には次が適用される。

  • nonce claim MUST be the value of nonce from the Authorization Request
  • aud claim MUST be the value of the Client Identifier\ ただし DC API 上の requests の場合は例外で、Appendix A.4 の通り origin: を prefix とする Origin でなければならない（MUST）

Key Binding JWT の unsecured payload の non-normative 例。

{
  "nonce": "n-0S6_WzA2Mj",
  "aud": "x509_san_dns:client.example.org",
  "iat": 1709838604,
  "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
  "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

B.3.7. SD-JWT VCLD

SD-JWT VCLD（SD-JWT Verifiable Credentials with JSON-LD）は、IETF SD-JWT VC（[I-D.ietf-oauth-sd-jwt-vc]）Credential format を拡張し、W3C VCDM（[VC_DATA]）のような Linked Data を用いる既存 data models を取り込みつつ、selective disclosure への一貫した簡潔なアプローチを可能にする。

SD-JWT VCLD Credentials に含まれる情報は、SD-JWT VC processing 後に JSON-LD processor（[JSON-LD]）で処理できる。

本仕様内で IETF SD-JWT VC に言及する場合、本 section で定義される SD-JWT VCLD を使用してよい（MAY）。

B.3.7.1. Format

SD-JWT VCLD Credentials は valid SD-JWT VCs であり、[I-D.ietf-oauth-sd-jwt-vc] の全要件が適用される。加えて、本 section の要件も適用される。

JWT processors との互換性のため、以下の registered Claims（[RFC7519] および [I-D.ietf-oauth-sd-jwt-vc]）は、W3C VCDM 等の counterpart properties の代わりに使用しなければならない（MUST）。

  • vct: Credential の type を表す
  • exp と nbf: SD-JWT VCLD の validity period（cryptographic signature）を表す
  • iss: Credential Issuer を表す
  • status: Credential の status を取得するための情報を表す

IETF SD-JWT VC は、次の claim で拡張される。

  • ld:
    • OPTIONAL
    • compact form の JSON-LD object（例: [VC_DATA]）を含む

B.3.7.2. Processing

SD-JWT VCLD の推奨 non-normative processing steps の outline は以下。

B.3.7.2.1. Step 1: SD-JWT VC Processing

SD-JWT VCLD の receiver（holder または verifier）は、[I-D.ietf-oauth-sd-jwt-vc] Section 4 で示される processing rules を適用する（signature 検証、validity periods、status 情報などを含む）。

vct 値が SD-JWT VC Type Metadata と関連付けられている場合、SD-JWT VCLD 全体（nested ld claim を含む）の schema validation が行われる。

加えて trust framework rules（例: 指定 vct に対して SD-JWT VCLDs を発行する権限が Credential Issuer にあることの確認）も適用される。

B.3.7.2.2. Step 2: Business Logic Processing

SD-JWT VC が SD-JWT VC processor により検証され trust された後、ld claim が存在するなら receiver は ld claim から JSON-LD object を抽出し、これを business logic object として用いる。ld claim が存在しないなら、SD-JWT VC 全体が business logic object を表すとみなされる。

その business logic object は、use case-specific なさらなる processing と validation のために渡される。business logic は security-critical functions（例: signature verification、trusted issuer）がすでに前 step で実施済みであることを前提とする。

追加の schema validation は ld claim が提供する場合に適用される（例: SHACL schemas のサポート）。vct claim は required だが、SD-JWT VC type metadata resolution とそれに伴う schema validation は、特定ケースでは optional である点に留意。

B.3.7.3. Examples

SD-JWT VCLD の unsecured payload の non-normative 例（selective disclosure の modifications 前、かつ validity claims 付与前）。

{
  "vct": "https://credentials.example.com/example_credential",
  "ld": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v3"
    ],
    "credentialSubject": {
      "givenName": "John",
      "familyName": "Doe",
      "birthDate": "1978-07-17"
    }
  }
}

上記 payload を encode し、credentialSubject 内の End-User specific claims に selective disclosure を有効化した後に SD-JWT で用いられる payload（non-normative）。

{
  "iss": "https://issuer.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "vct": "https://credentials.example.com/example_credential",
  "ld": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v3"
    ],
    "credentialSubject": {
      "_sd": [
        "6BJdQrO24ejTTMsFI-wGiJJmGrbseWc5IwCCp4NAJ0k",
        "NTDVsbVAwS9AnUVq-_YG_wv0yGD0bv2JstX-AmvN65I",
        "ts0pyPntLjD0_NcgNOI3hd_2WjbZw21p2LfqhOC0b-U"
      ]
    }
  },
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

Note: どの claims を selectively disclosable にするかは Credential の Issuer が決定する。考慮事項は [I-D.ietf-oauth-selective-disclosure-jwt] の Section 6 と Section 9.7 を参照。

Appendix C. Combining this specification with SIOPv2

本 section は、SIOP と OpenID for Verifiable Presentations を組み合わせて、Credentials を提示しつつ、subject controlled key material を用いて End-User を pseudonymously authenticate する方法を示す。

C.1. Request

本仕様と [SIOPv2] を組み合わせた request の non-normative 例。

GET /authorize?
  response_type=vp_token%20id_token
  &scope=openid
  &id_token_type=subject_signed
  &client_id=x509_san_dns%3Aclient.example.org
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &dcql_query=...
  &nonce=n-0S6_WzA2Mj HTTP/1.1
Host: wallet.example.com

この request が、前 sections の example requests と異なる点は次の通り。

  • response_type が vp_token id_token に設定されている。これは、Section 8 に記載の通り Wallet が同一 response に id_token parameter とともに vp_token parameter を返すことを意味する。
  • request は scope parameter に openid を含み、OpenID Connect request になる。さらに id_token_type=subject_signed を含み、Self-Issuer ID Token を要求している（すなわち SIOP request）。

C.2. Response

Appendix C.1 の request に対して送られる response の non-normative 例。

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
  id_token=
  &vp_token=...

vp_token に加えて id_token も含む。

上記 response に含まれる Self-Issued ID Token（[SIOPv2]）の payload の non-normative 例。

{
  "iss": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs",
  "sub": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs",
  "aud": "x509_san_dns:client.example.org",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970
}

Note: nonce と aud は、それぞれ request の nonce と Verifier の Client Identifier に設定され、replay 防止のため Verifiable Presentations の場合と同様である。

Appendix D. Examples for DCQL Queries

Example 1: mso_mdoc（vehicle_holder / first_name）

mso_mdoc format の Verifiable Credential を要求し、claims vehicle_holder と first_name を要求する DCQL query の non-normative 例。

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.7367.1.mVRC"
      },
      "claims": [
        { "path": ["org.iso.7367.1", "vehicle_holder"] },
        { "path": ["org.iso.18013.5.1", "first_name"] }
      ]
    }
  ]
}

Example 2: 複数 Credentials を要求（すべて MUST return）

複数の Verifiable Credentials を要求し、それらすべてが返されなければならない（all of them must be returned）DCQL query の non-normative 例。

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://credentials.example.com/identity_credential"]
      },
      "claims": [
        { "path": ["given_name"] },
        { "path": ["family_name"] },
        { "path": ["address", "street_address"] }
      ]
    },
    {
      "id": "mdl",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.7367.1.mVRC"
      },
      "claims": [
        { "path": ["org.iso.7367.1", "vehicle_holder"] },
        { "path": ["org.iso.18013.5.1", "first_name"] }
      ]
    }
  ]
}

Example 3: complex query（options / required=false）

Wallet が pid または other_pid または（pid_reduced_cred_1 と pid_reduced_cred_2 の両方）を返すよう要求する。加えて nice_to_have は optional として返されてもよい（may optionally be delivered）DCQL query の non-normative 例。

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://credentials.example.com/identity_credential"]
      },
      "claims": [
        { "path": ["given_name"] },
        { "path": ["family_name"] },
        { "path": ["address", "street_address"] }
      ]
    },
    {
      "id": "other_pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://othercredentials.example/pid"]
      },
      "claims": [
        { "path": ["given_name"] },
        { "path": ["family_name"] },
        { "path": ["address", "street_address"] }
      ]
    },
    {
      "id": "pid_reduced_cred_1",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.example.com/reduced_identity_credential"
        ]
      },
      "claims": [
        { "path": ["family_name"] },
        { "path": ["given_name"] }
      ]
    },
    {
      "id": "pid_reduced_cred_2",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://cred.example/residence_credential"]
      },
      "claims": [
        { "path": ["postal_code"] },
        { "path": ["locality"] },
        { "path": ["region"] }
      ]
    },
    {
      "id": "nice_to_have",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://company.example/company_rewards"]
      },
      "claims": [
        { "path": ["rewards_number"] }
      ]
    }
  ],
  "credential_sets": [
    {
      "options": [
        ["pid"],
        ["other_pid"],
        ["pid_reduced_cred_1", "pid_reduced_cred_2"]
      ]
    },
    {
      "required": false,
      "options": [
        ["nice_to_have"]
      ]
    }
  ]
}

Example 4: ID と address（mDL or photoid から選択）

ID と address を要求し、いずれも mDL または photoid Credential から来てよい DCQL query の例（non-normative）。

{
  "credentials": [
    {
      "id": "mdl-id",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      },
      "claims": [
        { "id": "given_name", "path": ["org.iso.18013.5.1", "given_name"] },
        { "id": "family_name", "path": ["org.iso.18013.5.1", "family_name"] },
        { "id": "portrait", "path": ["org.iso.18013.5.1", "portrait"] }
      ]
    },
    {
      "id": "mdl-address",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      },
      "claims": [
        {
          "id": "resident_address",
          "path": ["org.iso.18013.5.1", "resident_address"]
        },
        {
          "id": "resident_country",
          "path": ["org.iso.18013.5.1", "resident_country"]
        }
      ]
    },
    {
      "id": "photo_card-id",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.23220.photoid.1"
      },
      "claims": [
        { "id": "given_name", "path": ["org.iso.18013.5.1", "given_name"] },
        { "id": "family_name", "path": ["org.iso.18013.5.1", "family_name"] },
        { "id": "portrait", "path": ["org.iso.18013.5.1", "portrait"] }
      ]
    },
    {
      "id": "photo_card-address",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.23220.photoid.1"
      },
      "claims": [
        {
          "id": "resident_address",
          "path": ["org.iso.18013.5.1", "resident_address"]
        },
        {
          "id": "resident_country",
          "path": ["org.iso.18013.5.1", "resident_country"]
        }
      ]
    }
  ],
  "credential_sets": [
    {
      "options": [
        ["mdl-id"],
        ["photo_card-id"]
      ]
    },
    {
      "required": false,
      "options": [
        ["mdl-address"],
        ["photo_card-address"]
      ]
    }
  ]
}

Example 5: claim_sets（必須 + 代替セット）

「必須 claims last_name と date_of_birth」および「postal_code か、もしそれが無ければ locality と region の両方」を要求する DCQL query の例（non-normative）。

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://credentials.example.com/identity_credential"]
      },
      "claims": [
        { "id": "a", "path": ["last_name"] },
        { "id": "b", "path": ["postal_code"] },
        { "id": "c", "path": ["locality"] },
        { "id": "d", "path": ["region"] },
        { "id": "e", "path": ["date_of_birth"] }
      ],
      "claim_sets": [
        ["a", "c", "d", "e"],
        ["a", "b", "e"]
      ]
    }
  ]
}

Example 6: values constraints（last_name / postal_code の値指定）

values constraints を使い、last_name と postal_code を特定の値で要求する Credential の query 例（non-normative）。

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://credentials.example.com/identity_credential"]
      },
      "claims": [
        {
          "path": ["last_name"],
          "values": ["Doe"]
        },
        { "path": ["first_name"] },
        { "path": ["address", "street_address"] },
        {
          "path": ["postal_code"],
          "values": ["90210", "90211"]
        }
      ]
    }
  ]
}

Appendix E. IANA Considerations

E.1. OAuth Authorization Endpoint Response Types Registry

本仕様は、[RFC6749] により設立された IANA "OAuth Authorization Endpoint Response Types" registry（[IANA.OAuth.Parameters]）に、以下の response_type values を登録する。

E.1.1. vp_token

  • Response Type Name: vp_token
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Specification Document(s): Section 8 of this specification

E.1.2. vp_token id_token

  • Response Type Name: vp_token id_token
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Specification Document(s): Section 8 of this specification

E.2. OAuth Parameters Registry

本仕様は、[RFC6749] により設立された IANA "OAuth Parameters" registry（[IANA.OAuth.Parameters]）に、以下の OAuth parameters を登録する。

E.2.1. dcql_query

  • Name: dcql_query
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

E.2.2. client_metadata

  • Name: client_metadata
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

E.2.3. request_uri_method

  • Name: request_uri_method
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

E.2.4. transaction_data

  • Name: transaction_data
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

E.2.5. wallet_nonce

  • Name: wallet_nonce
  • Parameter Usage Location: authorization request, token response
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.10 of this specification

E.2.6. response_uri

  • Name: response_uri
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 8.2 of this specification

E.2.7. vp_token

  • Name: vp_token
  • Parameter Usage Location: authorization response, token response
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 8.1 of this specification

E.2.8. verifier_info

  • Name: verifier_info
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

E.2.9. expected_origins

  • Name: expected_origins
  • Parameter Usage Location: authorization request
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Appendix A.2 of this specification

E.3. OAuth Extensions Error Registry

本仕様は、[RFC6749] により設立された IANA "OAuth Extensions Error" registry（[IANA.OAuth.Parameters]）に、以下の errors を登録する。

E.3.1. vp_formats_not_supported

  • Name: vp_formats_not_supported
  • Usage Location: authorization endpoint, token endpoint
  • Protocol Extension: OpenID for Verifiable Presentations
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 8.5 of this specification

E.3.2. invalid_request_uri_method

  • Name: invalid_request_uri_method
  • Usage Location: authorization endpoint
  • Protocol Extension: OpenID for Verifiable Presentations
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 8.5 of this specification

E.3.3. wallet_unavailable

  • Name: wallet_unavailable
  • Usage Location: authorization endpoint, token endpoint
  • Protocol Extension: OpenID for Verifiable Presentations
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 8.5 of this specification

E.4. OAuth Authorization Server Metadata Registry

本仕様は、[RFC8414] により設立された IANA "OAuth Authorization Server Metadata" registry（[IANA.OAuth.Parameters]）に、以下の authorization server metadata parameters を登録する。

E.4.1. vp_formats_supported

  • Metadata Name: vp_formats_supported
  • Metadata Description: An object containing a list of name/value pairs, where the name is a string identifying a Credential format supported by the Wallet
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 10 of this specification

E.5. OAuth Dynamic Client Registration Metadata Registry

本仕様は、[RFC7591] により設立された IANA "OAuth Dynamic Client Registration Metadata" registry（[IANA.OAuth.Parameters]）に、以下の client metadata parameters を登録する。

E.5.1. encrypted_response_enc_values_supported

  • Client Metadata Name: encrypted_response_enc_values_supported
  • Client Metadata Description: Non-empty array of strings, where each string is a JWE [RFC7516] enc algorithm that can be used as the content encryption algorithm for encrypting the Response
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

E.5.2. vp_formats_supported

  • Client Metadata Name: vp_formats_supported
  • Client Metadata Description: An object containing a list of name/value pairs, where the name is a string identifying a Credential format supported by the Verifier
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 11.1 of this specification

E.6. Media Types Registry

本 section は、[RFC6838] で述べる方法に従い、IANA "Media Types" registry（）に、以下の media type（[RFC2046]）を登録する。

E.6.1. application/verifier-attestation+jwt

Verifier Attestation JWT の media type は application/verifier-attestation+jwt である。

  • Type name: application
  • Subtype name: verifier-attestation+jwt
  • Required parameters: n/a
  • Optional parameters: n/a
  • Encoding considerations: [RFC7515] で定義される JWS Compact Serialization を使用
  • Security considerations: [RFC7519] の Security Considerations を参照
  • Interoperability considerations: n/a
  • Published specification: Section 12 of this specification
  • Applications that use this media type: Applications that issue, present, verify Verifier attestation VCs
  • Additional information:
    • Magic number(s): n/a
    • File extension(s): n/a
    • Macintosh file type code(s): n/a
    • Person & email address to contact for further information: TBD
  • Intended usage: COMMON
  • Restrictions on usage: none
  • Author: Oliver Terbu, oliver.terbu@mattr.global
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net

E.7. JSON Web Signature and Encryption Header Parameters Registry

本仕様は、[RFC7515] により設立された IANA "JSON Web Signature and Encryption Header Parameters" registry（[IANA.JOSE]）に、以下の JWS header parameters を登録する。

E.7.1. jwt

  • Header Parameter Name: jwt
  • Header Parameter Description: This header contains a JWT. Processing rules MAY depend on the typ header value of the respective JWT.
  • Header Parameter Usage Location: JWS
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Specification Document(s): Section 12 of this specification

E.7.2. client_id

  • Header Parameter Name: client_id
  • Header Parameter Description: This header contains a Client Identifier. A Client Identifier is used in OAuth to identify a certain client. It is defined in [RFC6749], section 2.2.
  • Header Parameter Usage Location: JWS
  • Change Controller: IETF
  • Specification Document(s): [RFC6749]

E.8. Uniform Resource Identifier (URI) Schemes Registry

本仕様は、IANA "Uniform Resource Identifier (URI) Schemes" registry（[IANA.URI.Schemes]）に以下の URI scheme を登録する。

E.8.1. openid4vp

  • URI Scheme: openid4vp
  • Description: Custom scheme used for Wallet invocation
  • Status: Provisional
  • Well-Known URI Support: -
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 13.1.2 of this specification

E.9. JSON Web Token Claims Registration

  • Claim Name: ld
  • Claim Description: JSON-LD object in compact form
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Appendix B.3.7 of this specification

Appendix F. Acknowledgements

We would like to thank Richard Barnes, Paul Bastian, Vittorio Bertocci, Christian Bormann, John Bradley, Marcos Caceres, Kim Cameron, Brian Campbell, Lee Campbell, Tim Cappalli, David Chadwick, Stefan Charsley, Gabe Cohen, Andrii Deinega, Rajvardhan Deshmukh, Giuseppe De Marco, Sander Dijkhuis, Mark Dobrinic, Pedro Felix, Daniel Fett, George Fletcher, Ryan Galluzzo, Timo Glastra, Sam Goto, Mark Haine, Martijn Haring, Fabian Hauck, Roland Hedberg, Joseph Heenan, Bjorn Hjelm, Alen Horvat, Andrew Hughes, Jacob Ideskog, Łukasz Jaromin, Edmund Jay, Michael B. Jones, Tom Jones, Judith Kahrer, Takahiko Kawasaki, Gaurav Khot, Niels Klomp, Ronald Koenig, Markus Kreusch, Adam Lemmon, Hicham Lozi, Daniel McGrogan, Jeremie Miller, Matthew Miller, Mirko Mollik, Kenichi Nakamura, Andres Olave, Gareth Oliver, Aaron Parecki, Nemanja Patrnogic, Joel Posti, Andreea Prian, Rolson Quadras, Javier Ruiz, Nat Sakimura, Dimitar Atanasov Stoikov, Arjen van Veen, Steve Venema, Jan Vereecken, David Waite, Jacob Ward, David Zeuthen, and Michael Zischg for their valuable feedback and contributions to this specification.

Appendix G. Notices

Copyright (c) 2025 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

Authors' Addresses

Oliver Terbu

  • MATTR
  • Email: oliver.terbu@mattr.global

Torsten Lodderstedt

  • SPRIND
  • Email: torsten@lodderstedt.net

Kristina Yasuda

  • SPRIND
  • Email: kristina.yasuda@sprind.org

Daniel Fett

  • Authlete
  • Email: mail@danielfett.de

Joseph Heenan

  • Authlete
  • Email: joseph@heenan.me.uk