From d6ee7cf31a63931ef885196fe2bd33d74f5d2404 Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Fri, 6 Feb 2026 12:11:23 +0100 Subject: [PATCH 1/4] 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. --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 11 ++++++++++- 1 file changed, 10 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 e6395379..2456093c 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -808,9 +808,13 @@ Depending on this assessment, the response from the Interactive Authorization En ### Interaction Required Response {#iae-interaction-required-response} By setting `status` to `require_interaction` in the response, the Authorization Server requests an additional user interaction. -In this case, the following keys MUST be present in the response as well: +In this case, the following key MUST be present in the response as well: * `type`: REQUIRED. String indicating which type of interaction is required, as defined below. The Authorization Server MUST NOT set this to a value that was not included in the `interaction_types_supported` parameter sent by the Wallet. + +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. The Wallet MUST include the most recently received `auth_session` in follow-up requests to the Interactive Authorization Endpoint. @@ -826,6 +830,8 @@ 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. * 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 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: ``` @@ -939,6 +945,8 @@ In this case, the Authorization server MUST include the key `request_uri` in the The Wallet MUST use the `request_uri` value to build an Authorization Request as defined in Section 4 of [@!RFC9126] and complete the rest of the authorization process as defined there. 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: ``` @@ -975,6 +983,7 @@ It is RECOMMENDED to use this extension point instead of modifying the OAuth pro See (#iae-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 200 OK From 46edbdad23630e7d8a41a66394e7047dc9ad55ed Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Fri, 27 Feb 2026 09:26:21 +0100 Subject: [PATCH 2/4] 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 2456093c..7a35078c 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -945,7 +945,7 @@ In this case, the Authorization server MUST include the key `request_uri` in the The Wallet MUST use the `request_uri` value to build an Authorization Request as defined in Section 4 of [@!RFC9126] and complete the rest of the authorization process as defined there. 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 21aa905122e02a0ae9851bdc3848296d7a0aab1c Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Fri, 27 Feb 2026 09:56:01 +0100 Subject: [PATCH 3/4] Clarify auth_session requirements on interaction types. --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 7 ++++++- 1 file changed, 6 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 7a35078c..6594dd4b 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -813,10 +813,15 @@ In this case, the following key MUST be present in the response as well: * `type`: REQUIRED. String indicating which type of interaction is required, as defined below. The Authorization Server MUST NOT set this to a value that was not included in the `interaction_types_supported` parameter sent by the Wallet. 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. +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. If a Wallet receives a `type` value that it does not recognize, it MUST abort the issuance process. From 5215b8c0b07f1d931a4b9f07c89d6627e802304b Mon Sep 17 00:00:00 2001 From: Frederik Krogsdal Jacobsen Date: Thu, 19 Mar 2026 13:18:32 +0100 Subject: [PATCH 4/4] 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 6594dd4b..94ed1f9d 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -815,7 +815,7 @@ In this case, the following key MUST be present in the response as well: 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: