From 1a99310eb1d950045e7b6075a44b41f7b3718308 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Tue, 27 Jan 2026 19:00:48 +0100 Subject: [PATCH 1/5] fix: uses expected URL instead of expected origins for iae flow --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index e6395379..64f1b636 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -824,7 +824,8 @@ Additional keys are defined based on the type of interaction, as shown next. If `type` is set to `openid4vp_presentation`, as shown in the following example, the response MUST further include an `openid4vp_request` parameter containing an OpenID4VP Authorization Request. The contents of the request is the same as for requests passed to the Digital Credentials API (see Appendix A.2 and Appendix A.3 of [@!OpenID4VP]), except as follows: * The `response_mode` MUST be either `iae-post` for unencrypted responses or `iae-post.jwt` for encrypted responses. These modes are used to indicate to the Wallet to return the response back to the same Interactive Authorization Endpoint. -* If `expected_origins` is present, it MUST contain only the derived Origin of the Interactive Authorization Endpoint as defined in Section 4 in [@RFC6454]. For example, the derived Origin from `https://example.com/iae` is `https://example.com`. +* The `expected_origins` parameter MUST NOT be present. +* When signed requests defined in A.3.2 of [@!OpenID4VP] are used, an addtional `expected_url` parameter MUST be present. The `expected_url` parameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. The following is a non-normative example of an unsigned Authorization Request: @@ -884,7 +885,7 @@ The exact architecture and the deployment of the Issuer's OpenID4VP Verifier is When processing the request the following logic applies: - 1. If `expected_origins` is present, the Wallet MUST ensure that `expected_origins` contains the derived Origin as defined above. + 1. If `expected_url` is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier. If the URL does not match value of the `expected_url`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. 2. If the response contains Verifiable Presentations that include Holder Binding, the audience of each of those MUST be properly bound to the Interactive Authorization Endpoint, following the rules defined by their Credential Format. Details on how to do this for each format can be found in the "Interactive Authorization Endpoint Binding" sections under (#format-profiles). Note that the Credential Format here refers to the format of the Verifiable Presentation requested in the OpenID4VP Authorization Request, which may be different from the format used for issuing the Credentials themselves. If any Verifiable Presentation with Holder Binding is not correctly bound to the Interactive Authorization Endpoint, the response MUST be rejected. The Interactive Authorization Request, which is used to submit the OpenID4VP Authorization Response MUST satisfy the requirements set out in (#follow-up-request). In addition to these requirements, the request MUST also contain the `openid4vp_response` parameter. The value of the `openid4vp_response` parameter is a JSON-encoded object that encodes the OpenID4VP Authorization Response parameters. In the case of an error it instead encodes the Authorization Error Response parameters. When the `response_mode` is `iae-post.jwt` the OpenID4VP Authorization Response MUST be encrypted according to Section 8.3 of [@!OpenID4VP]. @@ -3383,6 +3384,11 @@ established by [@!RFC6749]. * Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net * Reference: (#token-request) of this specification +* Name: `expected_url` +* Parameter Usage Location: authorization request +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#interactive-authorization-endpoint) this specification + ## OAuth Authorization Server Metadata Registry This specification registers the following authorization server metadata parameter @@ -3609,3 +3615,4 @@ The technology described in this specification was made available from contribut * use derived origin for `expected_origins` in IAE flow * add require_interactive_authorization_request to AS metadata * add interactive_authorization_endpoint to AS metadata section + * use `expected_url` instead of `expected_origins` for IAE flow From abe5965eeed935841161ef9dcc09fd3207cddf68 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Wed, 18 Feb 2026 21:27:19 +0100 Subject: [PATCH 2/5] Apply suggestion from @awoie --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 5a98eb3e..8920e4ab 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -825,7 +825,7 @@ If `type` is set to `openid4vp_presentation`, as shown in the following example, * The `response_mode` MUST be either `iae_post` for unencrypted responses or `iae_post.jwt` for encrypted responses. These modes are used to indicate to the Wallet to return the response back to the same Interactive Authorization Endpoint. * The `expected_origins` parameter MUST NOT be present. -* When signed requests defined in A.3.2 of [@!OpenID4VP] are used, an addtional `expected_url` parameter MUST be present. The `expected_url` parameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. +* When signed requests defined in A.3.2 of [@!OpenID4VP] are used, an addtional `expected_url` parameter MUST be present. The `expected_url` parameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. In the `openid4vp_presentation` interaction type, `expected_url` MUST be set to the Interactive Authorization Endpoint. The following is a non-normative example of an unsigned Authorization Request: From 621d96a6089d3a08e5b7df217f9c7e4830888dab Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Wed, 18 Feb 2026 21:21:52 +0100 Subject: [PATCH 3/5] fix: removed redudant history entry; fixed SD-JWT VC IAE binding section; applied Tim's suggestion --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 8920e4ab..192e3496 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1007,7 +1007,7 @@ This may lead to the malicious Authorization Server gaining access to Credential Custom extensions ((#iae-custom-extensions)) MUST ensure that this attack is prevented by ensuring one or both of the following: - 1. The Wallet is able to detect that a request is not presented by the party that initiated the Interactive Authorization Request. In the case of the (#iae-require-presentation) interaction with a signed Presentation request, this is achieved by the Wallet verifying the `expected_origins` parameter in the request, which contains the derived Origin of the Interactive Authorization Endpoint that initiated the request. + 1. The Wallet is able to detect that a request is not presented by the party that initiated the Interactive Authorization Request. In the case of the (#iae-require-presentation) interaction with a signed Presentation request, this is achieved by the Wallet verifying the `expected_url` parameter in the request, which contains the Interactive Authorization Endpoint that initiated the request. 2. The Authorization Server is able to detect that the request was forwarded to a different endpoint. In the case of the (#iae-require-presentation) interaction, this is achieved for both signed and unsigned requests by the binding the Interactive Authorization Endpoint to the Verifiable Presentation (see "Interactive Authorization Endpoint Binding" sections under (#format-profiles)), which is then verified by the Authorization Server. ### Authorization Code Response {#iae-authorization-code-response} @@ -2852,7 +2852,7 @@ The following is a non-normative example of a Credential Response containing a C ### Interactive Authorization Endpoint Binding {#iae-binding-sd-jwt-vc} -To bind the Interactive Authorization Endpoint to a Verifiable Presentation using the Credential Format defined in this section, the `aud` claim in the Key Binding JWT MUST be set to the derived Origin (as defined in (#iae-require-presentation)) of the Interactive Authorization Endpoint, prefixed with `iae:` (e.g., `iae:https://example.com`). +To bind the Interactive Authorization Endpoint to a Verifiable Presentation using the Credential Format defined in this section, the `aud` claim in the Key Binding JWT MUST be set to the Interactive Authorization Endpoint, prefixed with `iae:` (e.g., `iae:https://example.com`). # Claims Description @@ -3629,7 +3629,6 @@ The technology described in this specification was made available from contribut * move IAE binding to dedicated format-specific sections * rename `iar:` prefix in `iae:` in IAE flow * rename `iar-post` response mode in `iae_post` in IAE flow - * use derived origin for `expected_origins` in IAE flow * add require_interactive_authorization_request to AS metadata * add interactive_authorization_endpoint to AS metadata section * use `expected_url` instead of `expected_origins` for IAE flow From ea9c1d19a8d20628ea24047f3a0720240ca966bd Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Tue, 24 Feb 2026 15:25:29 +0100 Subject: [PATCH 4/5] Applied Timo's suggestion Co-authored-by: Timo Glastra --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 192e3496..4369a3ff 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -885,7 +885,7 @@ The exact architecture and the deployment of the Issuer's OpenID4VP Verifier is When processing the request the following logic applies: - 1. If `expected_url` is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier. If the URL does not match value of the `expected_url`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. + 1. If `expected_url` is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier. If the URL does not match the value of the `expected_url`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. 2. If the response contains Verifiable Presentations that include Holder Binding, the audience of each of those MUST be properly bound to the Interactive Authorization Endpoint, following the rules defined by their Credential Format. Details on how to do this for each format can be found in the "Interactive Authorization Endpoint Binding" sections under (#format-profiles). Note that the Credential Format here refers to the format of the Verifiable Presentation requested in the OpenID4VP Authorization Request, which may be different from the format used for issuing the Credentials themselves. If any Verifiable Presentation with Holder Binding is not correctly bound to the Interactive Authorization Endpoint, the response MUST be rejected. The Interactive Authorization Request, which is used to submit the OpenID4VP Authorization Response MUST satisfy the requirements set out in (#follow-up-request). In addition to these requirements, the request MUST also contain the `openid4vp_response` parameter. The value of the `openid4vp_response` parameter is a JSON-encoded object that encodes the OpenID4VP Authorization Response parameters. In the case of an error it instead encodes the Authorization Error Response parameters. When the `response_mode` is `iae_post.jwt` the OpenID4VP Authorization Response MUST be encrypted according to Section 8.3 of [@!OpenID4VP]. From 4f06c02fe27811cf80983b82affbc6b689ae0bd7 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 26 Feb 2026 17:51:35 +0100 Subject: [PATCH 5/5] Applied Timo's suggestion Co-authored-by: Timo Glastra --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 4369a3ff..26f09bf0 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -2852,7 +2852,7 @@ The following is a non-normative example of a Credential Response containing a C ### Interactive Authorization Endpoint Binding {#iae-binding-sd-jwt-vc} -To bind the Interactive Authorization Endpoint to a Verifiable Presentation using the Credential Format defined in this section, the `aud` claim in the Key Binding JWT MUST be set to the Interactive Authorization Endpoint, prefixed with `iae:` (e.g., `iae:https://example.com`). +To bind the Interactive Authorization Endpoint to a Verifiable Presentation using the Credential Format defined in this section, the `aud` claim in the Key Binding JWT MUST be set to the Interactive Authorization Endpoint, prefixed with `iae:` (e.g., `iae:https://example.com`). # Claims Description