From 33ebd75cd045799d627ac920f2607c43c47066f0 Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Fri, 6 Feb 2026 12:11:23 +0100 Subject: [PATCH 1/6] Make auth_session optional if other binding mechanism exists. The auth_session parameter is not needed in the all Interaction Required Responses since some interaction types already include a way to associate the next request with the ongoing auth sequence. This makes the requirement for auth_session conditional on there not being some other mechanism for binding the request to the auth sequence. It also adds a description of why the auth_session is not necessary in the redirect_to_web case and the custom example. --- ...id-4-verifiable-credential-issuance-1_1.md | 19 +++++++++++++++++-- 1 file changed, 17 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 a0af675f..e18418e6 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -783,15 +783,25 @@ The response to an Authorization Challenge Request is an HTTP message with the c 3. an error as defined in Section 5.2.2 of [@!I-D.ietf-oauth-first-party-apps], including the additional error codes defined in (#ia-error-response). ### Interaction Required Response {#ia-interaction-required-response} - By setting `error_code` to `insufficient_authorization` in the response with HTTP response code 401 `Unauthorized`, the Authorization Server requests an additional user interaction. In this case, the following keys MUST be present in the response as well: * `interaction_type_required`: REQUIRED. String indicating which type of interaction is required, as defined below. The Authorization Server MUST set this to a value that was included in the `interaction_types_supported` parameter sent by the Wallet. If the Authorization Server cannot fulfill the request using any of the supported types, it MUST reject the request with an Authorization Challenge Error Response, as defined in (#ia-error-response). -* `auth_session`: REQUIRED. As defined in Section 5.2.2 of [@!I-D.ietf-oauth-first-party-apps] If a Wallet receives an `interaction_type_required` value that it does not support, it MUST abort the issuance process. +The Authorization Server MUST provide a mechanism to associate the next request by this Wallet with the ongoing authorization request sequence. +If no other mechanism to associate the next request by this Wallet with the ongoing authorization request sequence is defined by the type of interaction, the following key MUST be present in the response as well: + +* `auth_session`: REQUIRED. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response. + +A definition of a custom type of interaction MUST include exactly one of the following: + +1. A normative requirement that the `auth_session` key MUST be included in the Interaction Required Response. +2. A definition of a mechanism to associate the next request by the Wallet with the ongoing authorization request sequence. + +The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Interactive Authorization Endpoint. + Additional keys are defined based on the type of interaction, as shown next. #### Require Presentation {#ia-require-presentation} @@ -801,6 +811,8 @@ If `interaction_type_required` is set to `urn:openid:dcp:ia:openid4vp_presentati * The `response_mode` MUST be either `ia_post` for unencrypted responses or `ia_post.jwt` for encrypted responses. When the Wallet receives one of these response modes, it MUST send its response to the same Authorization Challenge Endpoint. * If `expected_origins` is present, it MUST contain only the derived Origin of the Authorization Challenge Endpoint as defined in Section 4 of [@RFC6454]. For example, the derived Origin from `https://example.com/authorize-challenge` is `https://example.com`. +The response MUST include the key `auth_session` to associate the next request by this Wallet with the ongoing authorization request sequence. + The following is a non-normative example of an unsigned Authorization Request: ``` @@ -916,6 +928,8 @@ The Wallet MUST only use a `request_uri` value once. Authorization servers SHOULD treat `request_uri` values as one-time use but MAY allow for duplicate requests due to a user reloading/refreshing their user agent. An expired request_uri MUST be rejected as invalid. The Authorization Server MAY include the `expires_in` key as defined in [@!RFC9126]. +Since the `request_uri` allows the Authorization Server to associate the Authorization Request with the ongoing authorization request sequence, no `auth_session` is needed. + Non-normative Example: ``` @@ -953,6 +967,7 @@ It is RECOMMENDED to use this extension point instead of modifying the OAuth pro See (#ia-security) for additional security considerations. In the following non-normative example, this extension point is used to read the Betelgeuse Intergalactic ID card through an NFC interface in the Wallet. A token called `biic_token` is used to start the process. +It is assumed that the `biic_token` is used by the Authorization Server to associate the next request by this Wallet with the ongoing authorization request sequence, and no `auth_session` is thus needed. ``` HTTP/1.1 401 Unauthorized From f39fe2c29858e0639e634394fad1b577cf8e0f9e Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Fri, 27 Feb 2026 09:26:21 +0100 Subject: [PATCH 2/6] Clarify auth_session behavior in redirect-to-web. Co-authored-by: Valentine Mazurov --- 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 e18418e6..b09d7b29 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -928,7 +928,7 @@ The Wallet MUST only use a `request_uri` value once. Authorization servers SHOULD treat `request_uri` values as one-time use but MAY allow for duplicate requests due to a user reloading/refreshing their user agent. An expired request_uri MUST be rejected as invalid. The Authorization Server MAY include the `expires_in` key as defined in [@!RFC9126]. -Since the `request_uri` allows the Authorization Server to associate the Authorization Request with the ongoing authorization request sequence, no `auth_session` is needed. +Since the `request_uri` allows the Authorization Server to associate the Authorization Request with the ongoing authorization request sequence, the Authorization Server MUST omit `auth_session` parameter in the response. The `auth_session` will be returned in the redirect back to the Wallet if required. Non-normative Example: From d09f2fb291060b5d7bab83e64aaa1a961c5ddfd8 Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Fri, 27 Feb 2026 09:56:01 +0100 Subject: [PATCH 3/6] Clarify auth_session requirements on interaction types. --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 9 ++++++++- 1 file changed, 8 insertions(+), 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 b09d7b29..58c023c2 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -791,7 +791,7 @@ In this case, the following keys MUST be present in the response as well: If a Wallet receives an `interaction_type_required` value that it does not support, it MUST abort the issuance process. The Authorization Server MUST provide a mechanism to associate the next request by this Wallet with the ongoing authorization request sequence. -If no other mechanism to associate the next request by this Wallet with the ongoing authorization request sequence is defined by the type of interaction, the following key MUST be present in the response as well: +The following key MAY be present in the response to provide such a mechanism: * `auth_session`: REQUIRED. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response. @@ -802,6 +802,13 @@ A definition of a custom type of interaction MUST include exactly one of the fol The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Interactive Authorization Endpoint. +A definition of a custom type of interaction MUST include exactly one of the following: + +1. A normative requirement that the `auth_session` key MUST be included in the Interaction Required Response. +2. A definition of a mechanism to associate the next request by the Wallet with the ongoing authorization request sequence. + +The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Interactive Authorization Endpoint. + Additional keys are defined based on the type of interaction, as shown next. #### Require Presentation {#ia-require-presentation} From 13255be9cc38bc7dc3cd8ffe4ab0690dee85a9da Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Thu, 19 Mar 2026 13:18:32 +0100 Subject: [PATCH 4/6] Make auth_session required only if interaction type requires it. --- 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 58c023c2..b7520b68 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -793,7 +793,7 @@ If a Wallet receives an `interaction_type_required` value that it does not suppo The Authorization Server MUST provide a mechanism to associate the next request by this Wallet with the ongoing authorization request sequence. The following key MAY be present in the response to provide such a mechanism: -* `auth_session`: REQUIRED. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response. +* `auth_session`: REQUIRED if specified by the interaction type. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response. A definition of a custom type of interaction MUST include exactly one of the following: From 1bab3fc8bc429c42102c1542a20f841b82b0d349 Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Mon, 29 Jun 2026 12:54:24 +0200 Subject: [PATCH 5/6] Remove duplicate text and align with new names. --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 9 +-------- 1 file changed, 1 insertion(+), 8 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 b7520b68..0de6f637 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -800,14 +800,7 @@ A definition of a custom type of interaction MUST include exactly one of the fol 1. A normative requirement that the `auth_session` key MUST be included in the Interaction Required Response. 2. A definition of a mechanism to associate the next request by the Wallet with the ongoing authorization request sequence. -The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Interactive Authorization Endpoint. - -A definition of a custom type of interaction MUST include exactly one of the following: - -1. A normative requirement that the `auth_session` key MUST be included in the Interaction Required Response. -2. A definition of a mechanism to associate the next request by the Wallet with the ongoing authorization request sequence. - -The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Interactive Authorization Endpoint. +The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Authorization Challenge Endpoint. Additional keys are defined based on the type of interaction, as shown next. From a2fa55cabe07a4e5c9658d65812f097c659d8324 Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Mon, 29 Jun 2026 12:58:38 +0200 Subject: [PATCH 6/6] Align with new names. --- 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 0de6f637..c71586b6 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -793,7 +793,7 @@ If a Wallet receives an `interaction_type_required` value that it does not suppo The Authorization Server MUST provide a mechanism to associate the next request by this Wallet with the ongoing authorization request sequence. The following key MAY be present in the response to provide such a mechanism: -* `auth_session`: REQUIRED if specified by the interaction type. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response. +* `auth_session`: REQUIRED if specified by the interaction type. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each authorization challenge response. A definition of a custom type of interaction MUST include exactly one of the following: