From 0bd8310e3125ba66612f206747dd4e8d0e0fce90 Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Wed, 11 Sep 2024 13:44:39 +0200 Subject: [PATCH 1/9] Update openid-4-verifiable-presentations-1_0.md Remove requirements to use the presentation exchange specification. --- openid-4-verifiable-presentations-1_0.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index f05229c..e083127 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -252,10 +252,10 @@ This specification enables the Verifier to send both Presentation Definition JSO This specification defines the following new parameters: `presentation_definition`: -: A string containing a Presentation Definition JSON object. See (#request_presentation_definition) for more details. This parameter MUST be present when `presentation_definition_uri` parameter, or a `scope` value representing a Presentation Definition is not present. +: OPTIONAL. A string containing a Presentation Definition JSON object. See (#request_presentation_definition) for more details. `presentation_definition_uri`: -: A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when `presentation_definition` parameter, or a `scope` value representing a Presentation Definition is not present. See (#request_presentation_definition_uri) for more details. +: OPTIONAL. A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. See (#request_presentation_definition_uri) for more details. `client_id_scheme`: : 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. @@ -572,11 +572,11 @@ When a VP Token is returned, the respective response MUST include the following : 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. +: OPTIONAL. 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. Other parameters, such as `state` or `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. `state` values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde). For the implementation considerations of a `state` parameter, see (#state_management). -The `presentation_submission` element MUST be included as a separate response parameter alongside the VP token. Clients MUST ignore any `presentation_submission` element included inside a Verifiable Presentation. +If present, the `presentation_submission` element MUST be included as a separate response parameter alongside the VP token. Clients MUST ignore any `presentation_submission` element included inside a Verifiable Presentation. Including the `presentation_submission` parameter as a separate response parameter allows the Wallet to provide the Verifier with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the Credential formats that do not allow for the direct inclusion of `presentation_submission` parameters inside a Credential itself. From 95e337ed25e4ed15200149b09316c3dabb63457b Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Thu, 12 Sep 2024 14:51:06 +0200 Subject: [PATCH 2/9] Apply suggestions from code review Prevent duplicates of presentation definition to be present. Clarify presence requirements for presentation_submission. Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> Co-authored-by: Joseph Heenan --- 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 e083127..2461291 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -252,10 +252,10 @@ This specification enables the Verifier to send both Presentation Definition JSO This specification defines the following new parameters: `presentation_definition`: -: OPTIONAL. A string containing a Presentation Definition JSON object. See (#request_presentation_definition) for more details. +: OPTIONAL. A string containing a Presentation Definition JSON object. See (#request_presentation_definition) for more details. This parameter MUST NOT be present when `presentation_definition_uri` parameter, or a `scope` value representing a Presentation Definition is present. `presentation_definition_uri`: -: OPTIONAL. A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. See (#request_presentation_definition_uri) for more details. +: OPTIONAL. A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST NOT be present when `presentation_definition` parameter, or a `scope` value representing a Presentation Definition is present. See (#request_presentation_definition_uri) for more details. `client_id_scheme`: : 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. @@ -572,7 +572,7 @@ When a VP Token is returned, the respective response MUST include the following : 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`: -: OPTIONAL. 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. +: OPTIONAL. The `presentation_submission` element as defined in [@!DIF.PresentationExchange]. It MUST be present if the `presentation_definition` or `presentation_definition_uri` parameters were present in the request, or if a `scope` value representing a presentation_definition was used. 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. Other parameters, such as `state` or `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. `state` values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde). For the implementation considerations of a `state` parameter, see (#state_management). From 514e7c7a3db0eaec24e78573dc04c7a9be6a5967 Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Tue, 24 Sep 2024 13:32:54 +0200 Subject: [PATCH 3/9] Apply suggestions from code review Apply suggestions that more precisely define when which request and response parameters can be present Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> Co-authored-by: Jan Vereecken --- openid-4-verifiable-presentations-1_0.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 2461291..75d11e8 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -252,10 +252,10 @@ This specification enables the Verifier to send both Presentation Definition JSO This specification defines the following new parameters: `presentation_definition`: -: OPTIONAL. A string containing a Presentation Definition JSON object. See (#request_presentation_definition) for more details. This parameter MUST NOT be present when `presentation_definition_uri` parameter, or a `scope` value representing a Presentation Definition is present. +: OPTIONAL. A string containing a Presentation Definition JSON object. See (#request_presentation_definition) for more details. This parameter MUST NOT be present if any of the following parameters are present: a `presentation_definition_uri` parameter, a `scope` parameter with a value representing a Presentation Definition, or any other parameter defined by this specification that indicates what credential is being requested. `presentation_definition_uri`: -: OPTIONAL. A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST NOT be present when `presentation_definition` parameter, or a `scope` value representing a Presentation Definition is present. See (#request_presentation_definition_uri) for more details. +: OPTIONAL. A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST NOT be present if any of the following parameters are present: a `presentation_definition` parameter, a `scope` parameter with a value representing a Presentation Definition, or any other parameter defined by this specification that indicates what credential is being requested. See (#request_presentation_definition_uri) for more details. `client_id_scheme`: : 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. @@ -572,11 +572,11 @@ When a VP Token is returned, the respective response MUST include the following : 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`: -: OPTIONAL. The `presentation_submission` element as defined in [@!DIF.PresentationExchange]. It MUST be present if the `presentation_definition` or `presentation_definition_uri` parameters were present in the request, or if a `scope` value representing a presentation_definition was used. 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. +: OPTIONAL. The `presentation_submission` element as defined in [@!DIF.PresentationExchange]. It MUST be present if any of the following parameters were present in the request: a `presentation_definition` parameter, a `presentation_definition_uri` parameter, or a `scope` parameter with a value representing a Presentation Definition. 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. Other parameters, such as `state` or `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. `state` values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde). For the implementation considerations of a `state` parameter, see (#state_management). -If present, the `presentation_submission` element MUST be included as a separate response parameter alongside the VP token. Clients MUST ignore any `presentation_submission` element included inside a Verifiable Presentation. +The `presentation_submission` element MAY be included as a separate response parameter alongside the VP token. Clients MUST ignore any `presentation_submission` element included inside a Verifiable Presentation. Including the `presentation_submission` parameter as a separate response parameter allows the Wallet to provide the Verifier with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the Credential formats that do not allow for the direct inclusion of `presentation_submission` parameters inside a Credential itself. From 1480349ed09ddd783cf2fc6ce89da648ec4f9a92 Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Tue, 24 Sep 2024 13:39:03 +0200 Subject: [PATCH 4/9] Update openid-4-verifiable-presentations-1_0.md Updated line 244 and 547 to be in line with other changes. --- openid-4-verifiable-presentations-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 75d11e8..66e3363 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -241,7 +241,7 @@ that signals to the Wallet that it can make an HTTP POST request to the Verifier endpoint with information about its capabilities as defined in (#request_uri_method_post). The Wallet MAY continue with JAR when it receives `request_uri_method` parameter with the value `post` but does not support this feature. -The Verifier articulates requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters that contain a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. Wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange] unless implementing only a credential profile that provides rules on how to evaluate and process [@!DIF.PresentationExchange]. +The Verifier MAY articulate requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters that contain a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. When processing this Presention Definiotn object, wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange] unless implementing only a credential profile that provides rules on how to evaluate and process [@!DIF.PresentationExchange]. 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. @@ -544,7 +544,7 @@ If the Verifier responds with any HTTP error response, the Wallet MUST terminate # Response {#response} -A VP Token is only returned if the corresponding Authorization Request contained a `presentation_definition` parameter, a `presentation_definition_uri` parameter, or a `scope` parameter representing a Presentation Definition (#vp_token_request). +A VP Token MAY be returned if the corresponding Authorization Request contained a `presentation_definition` parameter, a `presentation_definition_uri` parameter, or a `scope` parameter representing a Presentation Definition (#vp_token_request). VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. From d2f19e53a9e27f81ca11ac616f32dc880365f7cd Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Tue, 24 Sep 2024 15:36:06 +0200 Subject: [PATCH 5/9] Update openid-4-verifiable-presentations-1_0.md fix typo Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- 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 66e3363..29fa288 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -241,7 +241,7 @@ that signals to the Wallet that it can make an HTTP POST request to the Verifier endpoint with information about its capabilities as defined in (#request_uri_method_post). The Wallet MAY continue with JAR when it receives `request_uri_method` parameter with the value `post` but does not support this feature. -The Verifier MAY articulate requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters that contain a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. When processing this Presention Definiotn object, wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange] unless implementing only a credential profile that provides rules on how to evaluate and process [@!DIF.PresentationExchange]. +The Verifier MAY articulate requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters that contain a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. When processing this Presentation Definition object, wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange] unless implementing only a credential profile that provides rules on how to evaluate and process [@!DIF.PresentationExchange]. 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. From ffc410aae4ec64e5859161e09f4fc44272a3a8a4 Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Thu, 3 Oct 2024 23:52:16 +1000 Subject: [PATCH 6/9] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 29fa288..d77cb69 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -576,7 +576,7 @@ When a VP Token is returned, the respective response MUST include the following Other parameters, such as `state` or `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. `state` values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde). For the implementation considerations of a `state` parameter, see (#state_management). -The `presentation_submission` element MAY be included as a separate response parameter alongside the VP token. Clients MUST ignore any `presentation_submission` element included inside a Verifiable Presentation. +When the `presentation_submission` element is present, it MUST be included as a separate response parameter alongside the VP token. Clients MUST ignore any `presentation_submission` element included inside a Verifiable Presentation. Including the `presentation_submission` parameter as a separate response parameter allows the Wallet to provide the Verifier with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the Credential formats that do not allow for the direct inclusion of `presentation_submission` parameters inside a Credential itself. From c4eb6d2b20a7d9e0213e756355d66d2ccbb79df9 Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Thu, 3 Oct 2024 23:52:57 +1000 Subject: [PATCH 7/9] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 d77cb69..9874a83 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -241,7 +241,7 @@ that signals to the Wallet that it can make an HTTP POST request to the Verifier endpoint with information about its capabilities as defined in (#request_uri_method_post). The Wallet MAY continue with JAR when it receives `request_uri_method` parameter with the value `post` but does not support this feature. -The Verifier MAY articulate requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters that contain a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. When processing this Presentation Definition object, wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange] unless implementing only a credential profile that provides rules on how to evaluate and process [@!DIF.PresentationExchange]. +The requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters are articulated by the Verifier using a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. When processing this Presentation Definition object, wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange] unless implementing only a credential profile that provides rules on how to evaluate and process [@!DIF.PresentationExchange]. 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. From fe35420a6a1dbb85c0b213d0ac518c48aa3d592c Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Fri, 4 Oct 2024 00:04:41 +1000 Subject: [PATCH 8/9] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-presentations-1_0.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 9874a83..0528adc 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -257,6 +257,8 @@ This specification defines the following new parameters: `presentation_definition_uri`: : OPTIONAL. A string containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST NOT be present if any of the following parameters are present: a `presentation_definition` parameter, a `scope` parameter with a value representing a Presentation Definition, or any other parameter defined by this specification that indicates what credential is being requested. See (#request_presentation_definition_uri) for more details. +One of the following parameters MUST be present to indicate what credential is being requested: a `presentation_definition` parameter, `presentation_definition_uri` parameter, a `scope` parameter with a value representing a Presentation Definition, or any other parameter defined for that purpose by this specification and all its future versions. + `client_id_scheme`: : 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. From 8893da0efae7e814b775d27453bc3128b0049d39 Mon Sep 17 00:00:00 2001 From: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Date: Fri, 4 Oct 2024 00:06:15 +1000 Subject: [PATCH 9/9] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 0528adc..36f4243 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -546,7 +546,7 @@ If the Verifier responds with any HTTP error response, the Wallet MUST terminate # Response {#response} -A VP Token MAY be returned if the corresponding Authorization Request contained a `presentation_definition` parameter, a `presentation_definition_uri` parameter, or a `scope` parameter representing a Presentation Definition (#vp_token_request). +A VP Token MUST be returned when the corresponding Authorization Request contained a `presentation_definition` parameter, a `presentation_definition_uri` parameter, or a `scope` parameter representing a Presentation Definition (#vp_token_request). VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details.