From 31f56990f5130423b907347927c2d0e4ee711a9a Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Sun, 25 Aug 2024 14:59:41 +0100 Subject: [PATCH 1/8] Clarify what can go in client_metadata authz request parameter As per working group consensus agreed on 21st May call: https://github.com/openid/OpenID4VP/issues/17#issuecomment-2123350290 closes #17 --- openid-4-verifiable-presentations-1_0.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index c1e58fec..f807267e 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -261,9 +261,13 @@ This specification defines the following new parameters: : OPTIONAL. A string identifying the scheme of the value in the `client_id` Authorization Request parameter (Client Identifier scheme). The `client_id_scheme` parameter namespaces the respective Client Identifier. If an Authorization Request uses the `client_id_scheme` parameter, the Wallet MUST interpret the Client Identifier of the Verifier in the context of the Client Identifier scheme. If the parameter is not present, the Wallet MUST behave as specified in [@!RFC6749]. See (#client_metadata_management) for the values defined by this specification. If the same Client Identifier is used with different Client Identifier schemes, those occurrences MUST be treated as different Verifiers. Note that the Verifier needs to determine which Client Identifier schemes the Wallet supports prior to sending the Authorization Request in order to choose a supported scheme. `client_metadata`: -: OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. +: OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. It may contain the following: -A public key to be used by the Wallet as an input to the key agreement to encrypt Authorization Response (see (#jarm)). It MAY be passed by the Verifier using the `jwks` or the `jwks_uri` claim within the `client_metadata` request parameter. + * `jwks`: OPTIONAL. A JWKS that can contain a public key to be used by the Wallet as an input to the key agreement to encrypt the Authorization Response (see (#jarm)). This does not replace any JWKS for the Verifier that the Wallet has obtained from other sources (e.g. keys for verifying signed requests may have been obtained from [@!OpenID.Federation]). + * `vp_formats`: REQUIRED when not available to the wallet via another mechanism. As defined in (#client_metadata_parameters). + * `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM]. + * `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM]. + * `authorization_encrypted_response_enc`: OPTIONAL. As defined in [@!JARM]. `request_uri_method`: : OPTIONAL. A string determining the HTTP method to be used when the `request_uri` parameter is included in the same request. Two case-sensitive valid values are defined in this specification: `get` and `post`. If `request_uri_method` value is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` value is `post`, a supporting Wallet MUST send the request using the HTTP POST method as detailed in (#request_uri_method_post). If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` parameter as defined in [@RFC9101]. Wallets not supporting the `post` method will send a GET request to the Request URI (default behavior as defined in [@RFC9101]). `request_uri_method` parameter MUST NOT be present if a `request_uri` parameter is not present. @@ -2048,6 +2052,10 @@ The technology described in this specification was made available from contribut [[ To be removed from the final specification ]] + -22 + + * clarified what can go in the `client_metadata` parameter + -21 * removed `client_metadata_uri` authorization parameter From c4a7c30cf70d28838dfbdf8044bdfc58d8dcc900 Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Wed, 28 Aug 2024 13:17:09 +0100 Subject: [PATCH 2/8] Attempt to address Martijn's feedback Try to make it clearer that other values mustn't be used in client_metadata unless an extension to this specification explicitly allows them to be used. --- openid-4-verifiable-presentations-1_0.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index f807267e..35171fab 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -245,7 +245,7 @@ The Verifier articulates requirements of the Credential(s) that are requested us The Verifier communicates a Client Identifier Scheme that indicate how the Wallet is supposed to interpret the Client Identifier and associated data in the process of Client identification, authentication, and authorization using `client_id_scheme` parameter. This parameter enables deployments of this specification to use different mechanisms to obtain and validate Client metadata beyond the scope of [@!RFC6749]. A certain Client Identifier Scheme MAY require the Verifier to sign the Authorization Request as means of authentication and/or pass additional parameters and require the Wallet to process them. -Depending on the Client Identifier Scheme, the Verifier can communicate a JSON object with its metadata using the `client_metadata` parameter which contains name/value pairs defined in Section 4.3 and Section 2.1 of the OpenID Connect Dynamic Client Registration 1.0 [@!OpenID.Registration] specification as well as [@!RFC7591]. +Depending on the Client Identifier Scheme, the Verifier can communicate a JSON object with its metadata using the `client_metadata` parameter which contains name/value pairs. This specification enables the Verifier to send both Presentation Definition JSON object and Client Metadata JSON object by value or by reference. @@ -261,14 +261,18 @@ This specification defines the following new parameters: : OPTIONAL. A string identifying the scheme of the value in the `client_id` Authorization Request parameter (Client Identifier scheme). The `client_id_scheme` parameter namespaces the respective Client Identifier. If an Authorization Request uses the `client_id_scheme` parameter, the Wallet MUST interpret the Client Identifier of the Verifier in the context of the Client Identifier scheme. If the parameter is not present, the Wallet MUST behave as specified in [@!RFC6749]. See (#client_metadata_management) for the values defined by this specification. If the same Client Identifier is used with different Client Identifier schemes, those occurrences MUST be treated as different Verifiers. Note that the Verifier needs to determine which Client Identifier schemes the Wallet supports prior to sending the Authorization Request in order to choose a supported scheme. `client_metadata`: -: OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. It may contain the following: +: OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used: - * `jwks`: OPTIONAL. A JWKS that can contain a public key to be used by the Wallet as an input to the key agreement to encrypt the Authorization Response (see (#jarm)). This does not replace any JWKS for the Verifier that the Wallet has obtained from other sources (e.g. keys for verifying signed requests may have been obtained from [@!OpenID.Federation]). + * `jwks`: OPTIONAL. A JWKS that can contain a public key with the `"use": "enc"` claim to be used by the Wallet as an input to the key agreement to encrypt the Authorization Response (see (#jarm)). This does not replace any JWKS for the Verifier that the Wallet has obtained from other sources (e.g. keys for verifying signed requests may have been obtained from [@!OpenID.Federation]). This allows the verifier to pass an empheral encryption key that is only used for this authorization request. * `vp_formats`: REQUIRED when not available to the wallet via another mechanism. As defined in (#client_metadata_parameters). * `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_enc`: OPTIONAL. As defined in [@!JARM]. + Values passed in `client_metadata` MUST NOT override authorative data the wallet is able to obtain about the client from other sources, for example those from an OpenID Federation Entity Statement. + + Other metadata parameters defined in, for example, Section 4.3 and Section 2.1 of the OpenID Connect Dynamic Client Registration 1.0 [@!OpenID.Registration] specification or [@!RFC7591] MUST NOT be used unless a profile of this specification explicitly defines them as usable in the `client_metadata` parameter. + `request_uri_method`: : OPTIONAL. A string determining the HTTP method to be used when the `request_uri` parameter is included in the same request. Two case-sensitive valid values are defined in this specification: `get` and `post`. If `request_uri_method` value is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` value is `post`, a supporting Wallet MUST send the request using the HTTP POST method as detailed in (#request_uri_method_post). If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` parameter as defined in [@RFC9101]. Wallets not supporting the `post` method will send a GET request to the Request URI (default behavior as defined in [@RFC9101]). `request_uri_method` parameter MUST NOT be present if a `request_uri` parameter is not present. @@ -731,7 +735,7 @@ The JWT response document MUST include `vp_token` and `presentation_submission` The key material used for encryption and signing SHOULD be determined using existing metadata mechanisms. -To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` or `jwks_uri` claim within the `client_metadata` request parameter, or within the metadata defined in the Entity Configuration when [@!OpenID.Federation] is used, or other mechanisms. +To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` claim within the `client_metadata` request parameter, or within the metadata defined in the Entity Configuration when [@!OpenID.Federation] is used, or other mechanisms. To sign the Authorization Response, the Wallet MUST use a private key that corresponds to a public key made available in its metadata. From 24bcd57fef2f62265a8a30ff708128ea7f6998f5 Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Tue, 10 Sep 2024 16:46:56 +0100 Subject: [PATCH 3/8] Apply various review comments --- openid-4-verifiable-presentations-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 35171fab..ba7fdbfd 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -263,15 +263,15 @@ This specification defines the following new parameters: `client_metadata`: : OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used: - * `jwks`: OPTIONAL. A JWKS that can contain a public key with the `"use": "enc"` claim to be used by the Wallet as an input to the key agreement to encrypt the Authorization Response (see (#jarm)). This does not replace any JWKS for the Verifier that the Wallet has obtained from other sources (e.g. keys for verifying signed requests may have been obtained from [@!OpenID.Federation]). This allows the verifier to pass an empheral encryption key that is only used for this authorization request. + * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591] that can contain one or more public keys with the `"use": "enc"` parameter to be used by the Wallet as an input to the key agreement to encrypt the Authorization Response (see (#jarm)). This allows the verifier to pass an empheral encryption key that is only used for this authorization request. Public keys included in the `jwks` parameter MUST NOT be used to verify the signature of signed Authorization Requests. * `vp_formats`: REQUIRED when not available to the wallet via another mechanism. As defined in (#client_metadata_parameters). * `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_enc`: OPTIONAL. As defined in [@!JARM]. - Values passed in `client_metadata` MUST NOT override authorative data the wallet is able to obtain about the client from other sources, for example those from an OpenID Federation Entity Statement. + Authoritative data the wallet is able to obtain about the client from other sources, for example those from an OpenID Federation Entity Statement, take precedence over the values passed in `client_metadata`. - Other metadata parameters defined in, for example, Section 4.3 and Section 2.1 of the OpenID Connect Dynamic Client Registration 1.0 [@!OpenID.Registration] specification or [@!RFC7591] MUST NOT be used unless a profile of this specification explicitly defines them as usable in the `client_metadata` parameter. + Other metadata parameters MUST be ignored unless a profile of this specification explicitly defines them as usable in the `client_metadata` parameter. `request_uri_method`: : OPTIONAL. A string determining the HTTP method to be used when the `request_uri` parameter is included in the same request. Two case-sensitive valid values are defined in this specification: `get` and `post`. If `request_uri_method` value is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` value is `post`, a supporting Wallet MUST send the request using the HTTP POST method as detailed in (#request_uri_method_post). If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` parameter as defined in [@RFC9101]. Wallets not supporting the `post` method will send a GET request to the Request URI (default behavior as defined in [@RFC9101]). `request_uri_method` parameter MUST NOT be present if a `request_uri` parameter is not present. From 97df212ba1e9f1d7e0e70dcab5b26a5f96b72a31 Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Tue, 10 Sep 2024 16:49:16 +0100 Subject: [PATCH 4/8] Removed no longer used reference to OID DCR. --- openid-4-verifiable-presentations-1_0.md | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index ba7fdbfd..43a9870f 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1361,22 +1361,6 @@ issuers in Self-Sovereign Identity ecosystems using TRAIN - - - OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1 - - NRI - - - Ping Identity - - - Microsoft - - - - - Hyperledger Indy Project From 555f05c763d0fdeced85f06f5463f52bafb9def5 Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Mon, 23 Sep 2024 09:34:15 +0100 Subject: [PATCH 5/8] Apply changes from code review The text has been genericised a little to allow keys that don't have use: enc to allow for algorithms like: https://datatracker.ietf.org/doc/draft-bastian-dvs-jose/ --- openid-4-verifiable-presentations-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 80d0ac72..ed536ee5 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -263,13 +263,13 @@ This specification defines the following new request parameters: `client_metadata`: : OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used: - * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591] that can contain one or more public keys with the `"use": "enc"` parameter to be used by the Wallet as an input to the key agreement to encrypt the Authorization Response (see (#jarm)). This allows the verifier to pass an empheral encryption key that is only used for this authorization request. Public keys included in the `jwks` parameter MUST NOT be used to verify the signature of signed Authorization Requests. - * `vp_formats`: REQUIRED when not available to the wallet via another mechanism. As defined in (#client_metadata_parameters). + * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as keys with the `"use": "enc"` parameter used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or keys for signature algorithms that require a public key of the Verifier. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. + * `vp_formats`: REQUIRED when not available to the Wallet via another mechanism. As defined in (#client_metadata_parameters). * `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_enc`: OPTIONAL. As defined in [@!JARM]. - Authoritative data the wallet is able to obtain about the client from other sources, for example those from an OpenID Federation Entity Statement, take precedence over the values passed in `client_metadata`. + Authoritative data the Wallet is able to obtain about the Client from other sources, for example those from an OpenID Federation Entity Statement, take precedence over the values passed in `client_metadata`. Other metadata parameters MUST be ignored unless a profile of this specification explicitly defines them as usable in the `client_metadata` parameter. From 6f19375608a26732ed50cf8430662442abd54318 Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Mon, 23 Sep 2024 13:31:45 +0100 Subject: [PATCH 6/8] Apply Paul's suggestion --- openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index ed536ee5..9bdd4af3 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -263,7 +263,7 @@ This specification defines the following new request parameters: `client_metadata`: : OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used: - * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as keys with the `"use": "enc"` parameter used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or keys for signature algorithms that require a public key of the Verifier. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. + * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as keys used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or keys for signature algorithms that require a public key of the Verifier. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. * `vp_formats`: REQUIRED when not available to the Wallet via another mechanism. As defined in (#client_metadata_parameters). * `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM]. From 91d1704b6b1f91837fa0bba856efbb62687fc35b Mon Sep 17 00:00:00 2001 From: Joseph Heenan Date: Fri, 27 Sep 2024 09:39:02 +0100 Subject: [PATCH 7/8] Update text around jwks to try to address Oliver's concern --- openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 9bdd4af3..c7c6afb2 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -263,7 +263,7 @@ This specification defines the following new request parameters: `client_metadata`: : OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used: - * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as keys used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or keys for signature algorithms that require a public key of the Verifier. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. + * `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as those used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or where the Wallet will require the public key of the Verifier to generate the Verifiable Presentation. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. * `vp_formats`: REQUIRED when not available to the Wallet via another mechanism. As defined in (#client_metadata_parameters). * `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM]. * `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM]. From 304b4a881d291a0d3f144014cb0340a3ef1b5d12 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Mon, 30 Sep 2024 17:29:54 +0200 Subject: [PATCH 8/8] clarify base64url definition (#270) editorial. 2 approvals. --- openid-4-verifiable-presentations-1_0.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index c7c6afb2..821d54f8 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -64,7 +64,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S # Terminology -This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User", "Entity", "Request Object", "Request URI" as defined by OpenID Connect Core [@!OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" and the term "Base64url Encoding" defined by JSON Web Signature (JWS) [@!RFC7515], the term "JSON Web Encryption (JWE)" defined by [@!RFC7516], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [@!OAuth.Responses]. +This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User", "Entity", "Request Object", "Request URI" as defined by OpenID Connect Core [@!OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" defined by JSON Web Signature (JWS) [@!RFC7515], the term "JSON Web Encryption (JWE)" defined by [@!RFC7516], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [@!OAuth.Responses]. + +Base64url-encoded denotes the URL-safe base64 encoding without padding defined in Section 2 of [@!RFC7515]. This specification also defines the following terms. In the case where a term has a definition that differs, the definition below is authoritative. @@ -505,7 +507,7 @@ The following parameters are defined to be included in the request to the Reques : OPTIONAL. A String containing a JSON object containing metadata parameters as defined in (#as_metadata_parameters). `wallet_nonce`: -: OPTIONAL. A String value used to mitigate replay attacks of the Authorization Request. When received, the Verifier MUST use it as the `wallet_nonce` value in the signed authorization request object. Value can be a base64url encoded, fresh, cryptographically random number with sufficient entropy. +: OPTIONAL. A String value used to mitigate replay attacks of the Authorization Request. When received, the Verifier MUST use it as the `wallet_nonce` value in the signed authorization request object. Value can be a base64url-encoded, fresh, cryptographically random number with sufficient entropy. If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter within the `wallet_metadata` parameter to pass the public key for the input to the key agreement. Other mechanisms to pass the encryption key can be used as well. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. @@ -584,7 +586,7 @@ The behavior with respect to the VP Token is unspecified for any other individua When a VP Token is returned, the respective response MUST include the following parameters: `vp_token`: -: REQUIRED. JSON String or JSON object that MUST contain a single Verifiable Presentation or an array of JSON Strings and JSON objects each of them containing a Verifiable Presentations. Each Verifiable Presentation MUST be represented as a JSON string (that is a Base64url encoded value) or a JSON object depending on a format as defined in Appendix A of [@!OpenID.VCI]. When a single Verifiable Presentation is returned, the array syntax MUST NOT be used. If Appendix A of [@!OpenID.VCI] defines a rule for encoding the respective Credential format in the Credential Response, this rules MUST also be followed when encoding Credentials of this format in the `vp_token` response parameter. Otherwise, this specification does not require any additional encoding when a Credential format is already represented as a JSON object or a JSON string. +: REQUIRED. JSON String or JSON object that MUST contain a single Verifiable Presentation or an array of JSON Strings and JSON objects each of them containing a Verifiable Presentations. Each Verifiable Presentation MUST be represented as a JSON string (that is a base64url-encoded value) or a JSON object depending on a format as defined in Appendix A of [@!OpenID.VCI]. When a single Verifiable Presentation is returned, the array syntax MUST NOT be used. If Appendix A of [@!OpenID.VCI] defines a rule for encoding the respective Credential format in the Credential Response, this rules MUST also be followed when encoding Credentials of this format in the `vp_token` response parameter. Otherwise, this specification does not require any additional encoding when a Credential format is already represented as a JSON object or a JSON string. `presentation_submission`: : REQUIRED. The `presentation_submission` element as defined in [@!DIF.PresentationExchange]. It contains mappings between the requested Verifiable Credentials and where to find them within the returned VP Token. This is expressed via elements in the `descriptor_map` array, known as Input Descriptor Mapping Objects. These objects contain a field called `path`, which, for this specification, MUST have the value `$` (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value `$[n]` (indexed path from root) when there are multiple Verifiable Presentations, where `n` is the index to select. Additional parameters can be defined by Credential Formats, see (#alternative_credential_formats) for details. @@ -1847,7 +1849,7 @@ See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO. ### Presentation Response -The VP Token contains the base64url encoded `DeviceResponse` CBOR structure as defined in ISO/IEC 18013-5 [@ISO.18013-5] or ISO/IEC 23220-4 [@ISO.23220-4]. Essentially, the `DeviceResponse` CBOR structure contains a signature or MAC over the `SessionTranscript` CBOR structure including the OpenID4VP-specific `Handover` CBOR structure. +The VP Token contains the base64url-encoded `DeviceResponse` CBOR structure as defined in ISO/IEC 18013-5 [@ISO.18013-5] or ISO/IEC 23220-4 [@ISO.23220-4]. Essentially, the `DeviceResponse` CBOR structure contains a signature or MAC over the `SessionTranscript` CBOR structure including the OpenID4VP-specific `Handover` CBOR structure. See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO.23220-4] for the latest examples on how to use the `presentation_submission` parameter and how to generate the Authorizaton Response for presenting Credentials in the mdoc format.