OpenID Connect Deferred Token Response Flow 1.0 - draft 00

1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.¶

1.2. Terminology

This specification uses the terms "Access Token", "Authorization Endpoint", "Authorization Request", "Authorization Response", "Authorization Code Grant", "Authorization Server", "Client", "Public Client", "Client Authentication", "Client Identifier", "Token Endpoint", "Token Request" and "Token Response" defined by OAuth 2.0 [RFC6749], the terms "OpenID Provider (OP)", "Relying Party (RP)", "End-User" and "Request Object" as defined by OpenID Connect Core [OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [RFC7519], and the term "DPoP Proof" defined by OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449].¶

This specification also defines the following terms:¶

Authentication Process

The steps taken by an OpenID Provider to authenticate an End-User. The process MAY depend on Identity Information provided by the End-User. For example, the Authentication Process might involve checking the integrity of the Identity Information. The nature of the Authentication Process is beyond the scope of this specification.¶

Identity Information

Information collected from the End-User by the OpenID Provider as input to the Authentication Process. For example, this might be a picture of a driver's license and a video of the End-User performing a series of gestures. The nature of the Identity Information is beyond the scope of this specification.¶

3.1. Authorization Server Metadata

OPs capable of handling the Deferred Token Response Flows MUST advertise support for it in its OAuth 2.0 Authorization Server Metadata [RFC8414] as follows:¶

response_types_supported

A deferred_code response type is introduced by this specification in order to indicate to the OP that a deferred authentication response is acceptable once the user interaction ends.¶

grant_types_supported

This specification introduces the Deferred grant type (an extension grant type as defined by Section 4.5 of [RFC6749]) with the value: urn:openid:params:grant-type:deferred¶

3.2. Client Registration Metadata

The following Client Metadata parameter is defined by this specification to be used during Client Registration as defined in [RFC7591]:¶

deferred_client_notification_endpoint

REQUIRED if the RP desires to be notified when the Authentication decision has been taken. It MUST be an HTTPS URL.¶

4.1. Deferred Code Response Type

This section registers a new Response Type, the deferred_code, in accordance with the stipulations in Section 8.4 of [RFC6749]. It also defines combinations of the deferred_code Response Type with other Response Types. The intended purpose of the deferred_code is that the response MUST contain a Deferred Authorization Code which can be used at the Token Endpoint.¶

deferred_code

When supplied as the response_type parameter in an OAuth 2.0 Authorization Request, a successful response MUST include the parameter deferred_code. The Authorization Server SHOULD NOT return an OAuth 2.0 Authorization Code, Access Token, or Access Token Type in a successful response to the grant request. The User Agent MUST be redirected to the supplied redirect_uri after all required interaction with End-User has been completed. The request MAY include a state parameter, and if so, the Authorization Server MUST echo its value as a response parameter when issuing either a successful response or an error response.¶

deferred_code code

When supplied as the response_type parameter in an OAuth 2.0 Authorization Request, a successful response MUST include either the parameter deferred_code or the parameter code. The Authorization Server SHOULD NOT return an OAuth 2.0 Access Token, or Access Token Type in a successful response to the grant request. The User Agent MUST be redirected to the supplied redirect_uri after all required interaction with End-User has been completed. The request MAY include a state parameter, and if so, the Authorization Server MUST echo its value as a response parameter when issuing either a successful response or an error response.¶

4.2. Authentication Request

Deferred Token Response introduces a new Authentication Request using the OAuth 2.0 Authorization Request. This request is the same as the Authentication request of the Authorization Code Flow introduced in Section 3.1.2.1 of [OpenID.Core] with the exception of the following parameter:¶

response_type

REQUIRED. Deferred Token Response value that determines the authorization processing flow to be used, including what parameters are returned from the endpoints used. This value MUST be either deferred_code or deferred_code code.¶

Relying Parties MAY present additional parameters in this request regarding to OAuth 2.0 extensions (such as Rich Authorization Requests). Authorization Servers MUST accept those parameters and process them accordingly.¶

The following is a non-normative example request that would be sent by the User Agent to the Authorization Server in response to a corresponding HTTP 302 redirect response by the Client (with line wraps within values for display purposes only):¶

GET /authorize?
  response_type=deferred_code
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &scope=openid%20profile%20email
  &nonce=n-0S6_WzA2Mj
  &state=af0ifjsldkj HTTP/1.1
Host: server.example.com

4.3. Authentication Request Validation

The OpenID Provider MUST validate the request received as follows:¶

1. Verify that the response_type parameter is present and has a value of either deferred_code or deferred_code code.¶
2. Check if the Client is registered to use the Deferred Token Response flow.¶
3. Validate the remaining Authentication Request parameters in accordance with Section 3.1.2.2 - Authentication Request Validation of [OpenID.Core].¶

Additional Authorization Request parameters regarding to OAuth 2.0 extensions MAY be used. In such cases, they MUST be validated according to their definitions.¶

If the OpenID Provider encounters any error, it MUST return an error response, per Section 12.¶

4.4. OpenID Provider Obtains End-User Authorization and Identity Information

Upon receiving a valid Authentication Request, the OpenID Provider (OP) determines whether End-User interaction is required to complete the authentication process. The OP MAY expose its own interaction interfaces through the User Agent, or it MAY utilize delegated or federated interaction interfaces operated by third‑party providers.¶

Through these interfaces, the OP MAY prompt the End-User to provide credentials, perform multi-factor authentication, or supply additional Identity Information (such as biometric data, government-issued documents, or other forms of verification).¶

The nature and extent of the Identity Information collected are determined by the OP's policies and the authentication requirements of the Relying Party (RP).¶

If no interaction is required, or the End-User successfully completes the required interaction, the OP continues processing the Authentication Request. If the End-User declines or fails to provide sufficient information, the OP MUST return an error response as defined in Section 12.¶

4.5. Authentication Request Acknowledgment

If the Authentication Request is successfully processed in accordance with Section 4.4, the OpenID Provider (OP) returns a response to the Relying Party indicating that the request has been accepted and any required user interaction has been completed.¶

If the response_type requested by the Relying Party was deferred_code code, the OpenID Provider MAY respond with a Successful Authentication Response as defined in Section 3.1.2.5 of [OpenID.Core] to indicate that the user was authenticated immediately. The remainder of the Authentication then proceeds as an Authorization Code Flow as defined in Section 3.1 of [OpenID.Core].¶

Otherwise, the response MUST be an Authentication Request Acknowledgment. Note that an Authentication Request Acknowledgment does not constitute a final Authentication Response, but rather serves as an indication that further processing is underway.¶

An Authentication Request Acknowledgment is composed of the following parameters:¶

deferred_code

REQUIRED. This is a unique identifier for the Authentication Request made by the Client. It MUST contain sufficient entropy (a minimum of 128 bits while 160 bits is RECOMMENDED) to make brute force guessing or forgery of a valid deferred_code computationally infeasible. The means of achieving this are implementation-specific, with possible approaches including secure pseudorandom number generation or cryptographically secured self-contained tokens. The OpenID Provider MUST restrict the characters used to 'A'-'Z', 'a'-'z', '0'-'9', '.', '-' and '_', to reduce the chance of the client incorrectly decoding or re-encoding the deferred_code; this character set was chosen to allow the server to use unpadded base64url if it wishes. The identifier MUST be treated as opaque by the client.¶

state

OAuth 2.0 state value. REQUIRED if the Authorization Request included the state parameter. Set to the value received from the Client.¶

The following is a non-normative example of an Authentication Request Acknowledgment:¶

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
  deferred_code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj

4.6. Authentication Request Acknowledgment Validation

Upon receiving an Authentication Request Acknowledgment, the Relying Party (RP) MUST validate the response as follows:¶

1. Ensure that the deferred_code parameter is present.¶
2. Verify that a code parameter is not present.¶
3. If the Client includes a state parameter in Authentication Requests, verify that the state parameter is present in the response. The Client MAY perform additional validation to match the state parameter response with the one present in the Authentication Request.¶

When the Client requests the deferred_code code response type, it MUST distinguish if the response being validated is an Authentication Request Acknowledgment or a Successful Authentication Response of [OpenID.Core]. This can be achieved by checking for the presence of the deferred_code parameter. Determining the type of response is crucial for the Client to proceed with the appropriate flow.¶

Responses containing both code and deferred_code parameters MUST be considered invalid.¶

Any unrecognized parameter MUST be ignored by the Client.¶

5.1. Deferred Code Exchange Request

The Deferred Code Exchange Request exchanges the deferred_code obtained in the Authentication Request Acknowledgment.¶

The Client makes an HTTP POST request to the Token Endpoint by sending the following parameters using the application/x-www-form-urlencoded format:¶

grant_type

REQUIRED. Value MUST be urn:openid:params:grant-type:deferred.¶

deferred_code

REQUIRED. The identifier of the Authentication Request, issued by the OP to the Client requesting the exchange.¶

deferred_notification_token

OPTIONAL. A bearer access token which the OP can use to access the Client's Deferred Notification Endpoint when sending a Ping Callback for this request.¶

Supported extension parameters from the OAuth 2.0 Token Request MAY be included in this request.¶

A DPoP proof MAY be included in this request. The RP SHOULD ensure that a public key is not reused across different Authentication Processes.¶

The following is a non-normative example of a Deferred Code Exchange Request (with line wraps within values for display purposes only):¶

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCRnMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JEQSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJBeDBwYjcyazRtZCIsImh0bSI6IlBPU1QiLCJodHUiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiIsImlhdCI6MTc2MzcyMzExMn0.uy3IfO-j8Yg4Aux0uGAuh7_m24WDCfWCUacRPWtFHS9J-HWASoiEqBsuxI1LN3V4To4Mn1ZRv0AVBxuOA6km3g
grant_type=urn:openid:params:grant-type:deferred&deferred_code=SplxlOBeZQQYbYS6WxSbIA&deferred_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255

5.2. Deferred Code Exchange Request Validation

The OP MUST validate the request received as follows:¶

1. Authenticate the Client in accordance with Section 9 of [OpenID.Core].¶
2. Ensure the Deferred Code was issued to the authenticated Client.¶
3. Verify that the Deferred Code is valid and has not been previously used.¶
4. If a DPoP proof was provided, validate it in accordance with Section 4.3 of [RFC9449].¶

5.3. Successful Deferred Code Exchange Response

After receiving and validating an authorized Deferred Code Exchange Request from the Client, the OpenID Provider returns an HTTP 200 OK response to the Client containing the following parameters encoded in application/json format:¶

deferred_auth_id

REQUIRED. The Deferred Authentication ID is a unique identifier for the Authentication Process. The identifier MUST be treated as opaque by the client.¶

expires_in

OPTIONAL. A JSON number with a positive integer value indicating the expiration time of the deferred_auth_id in seconds. Some requests may naturally become irrelevant once some amount of time has passed. The OP MAY indicate that this is the case by returning a value in this parameter. The method of determining this value is outside the scope of this specification. Clients SHOULD support arbitrarily large values for this parameter.¶

interval

OPTIONAL. A JSON number with a positive integer value indicating the minimum amount of time in seconds that the Client MUST wait between polling requests to the token endpoint. Clients SHOULD support arbitrarily large values for this parameter.¶

interim_id_token

OPTIONAL. In some cases, the OP can immediately authenticate parts of the Identity Information provided by the End User. In some cases, the Client is interested in the Identity Information provided by the End User even before it is validated by the OP. To support this, the OP MAY include an Interim ID Token containing partially verified claims. The method by which the OP indicates the validation status of each claim is outside the scope of this specification.¶

Once redeemed for a successful Deferred Code Exchange Response, the deferred_code value that was used is no longer valid.¶

The OP MUST bind the public key used in DPoP proofs to deferred_auth_id when the Client is of type Public Client and a DPoP proof is presented in the Deferred Code Exchange Request. Further interactions involving a deferred_auth_id MUST require a DPoP proof utilizing the same public key. This mechanism is similar to the binding of DPoP proofs to Refresh Tokens as described in Section 5 of [RFC9449].¶

Clients MUST ignore unrecognized response parameters.¶

If the Client sent a deferred_notification_token in the Deferred Code Exchange Request, the Client SHOULD bind the received deferred_auth_id to the deferred_notification_token to prevent mix-up attacks.¶

The following is a non-normative example of a successful Deferred Code Exchange Response:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "deferred_auth_id": "f4oirNBUlM",
  "expires_in": 10800
  "interval": 60,
  "interim_id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjI3MTdmMzAzYTI3NjVlOGFjYmY0MTEwMGFhOGE0NjllIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiZW1haWwiOiJqb2huZG9lQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJhdWQiOiJzNkJoZFJrcXQzIiwibm9uY2UiOiJuLTBTNl9XekEyTWoiLCJleHAiOjE3NjIxOTE2ODgsImlhdCI6MTc2MjE5MTk4OH0.TmW5LZmr5tM_gDbk6Tc7VAMw6zYv9eo1BqbKf19rhw8cHsPLLMA25YilywdA66KO2ESWvY3S5YJn3Azypri5jQOeQTmPQZAeXHjcVSBeABzAQz3eGIdtAaDLQ5p0DafdxgEDOrcLLK8yk3X16aBGpJegdBY1HfqAhuYPV2D_LUCeGbJxn0-4nLF9_U7Ws3c4o_3nq9ZNTVEAoJJckRYhXM6pPf2-1tZvRZD2P9B0vPSiJwqN2JFOBoDROwhxPJU4MKWQ3mp5pdGTZqlUL7wn0a2dG-EI1eq6oQrGwINqTHiqZbttCuz1wQtezRxHYITEAoVaI2c3zad0ZSzTbAGNkw"
}

5.4. Deferred Code Exchange Response Validation

Upon receiving a Successful Deferred Code Exchange Response, the Relying Party (RP) MUST validate the response as follows:¶

1. Ensure that the deferred_auth_id parameter is present.¶
2. If an interim_id_token is present, validate it in accordance with Section 3.1.3.7 of [OpenID.Core].¶

The Client MUST retain the deferred_auth_id to validate Ping callbacks and to use when making Token or Cancellation requests.¶

The Client SHOULD store the expiration time in order to clean up authentication requests for which no Ping Callback is received.¶

8.1. Token Request using the Authentication Request ID

The Client makes an HTTP POST request to the Token Endpoint by sending the following parameters using the application/x-www-form-urlencoded format:¶

grant_type

REQUIRED. Value MUST be urn:openid:params:grant-type:deferred.¶

deferred_auth_id

REQUIRED. The unique identifier of the Authentication Process, issued by the OP to the Client requesting the token.¶

The RP MUST present a DPoP proof in this request if the Deferred Code Exchange Request included one. If the RP's Client is a Public Client, the DPoP proof MUST use the same public key used in the Deferred Code Exchange Request. Public keys SHOULD NOT be reused across different Authentication Processes.¶

The following is a non-normative example of a deferred token request:¶

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCRnMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JEQSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJwS2piNGFEZjEiLCJodG0iOiJQT1NUIiwiaHR1IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iLCJpYXQiOjE3NjM3MjMyMjB9.4dr1uoyy8m1giIcVgfsXmO_WISirgOAJxqJZul58QCu_MdxOBZ76HNO70BNyF8NJdv8HACS54etcvBr6C2iXxg

grant_type=urn:openid:params:grant-type:deferred&deferred_auth_id=f4oirNBUlM

8.2. Token Request Validation

The OP MUST validate the request received as follows:¶

1. Authenticate the Client in accordance with Section 9 of [OpenID.Core].¶
2. Ensure the given deferred_auth_id was issued to the authenticated Client.¶
3. If expires_in was provided in Section 5.3, verify that the expiration time has not elapsed.¶

4. If a DPoP proof was provided in the Deferred Code Exchange Request¶

   1. Validate that a DPoP proof is provided in this request.¶
   2. If the Client is a Public Client, verify that the public key used in this DPoP proof matches the one used in the Deferred Code Exchange Request.¶
5. If a DPoP proof is provided in this request, validate it in accordance with Section 4.3 of [RFC9449].¶
6. Verify that the Authentication Process has been completed, has not been canceled and has not reached timeout¶
7. Verify that no access token has been previously issued for the Deferred Authentication ID.¶

If the OP encounters any error, it MUST return an error response, per Section 10.¶

8.3. Successful Token Response

After receiving and validating an authorized Token Request from the Client, and once the End User associated with the supplied deferred_auth_id has been authenticated, the OpenID Provider returns a successful response as defined in Section 3.1.3.3 of [OpenID.Core]. After it has been redeemed for a successful Token response, the used deferred_auth_id value becomes invalid.¶

The following is a non-normative example of a successful token response:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "SlAV32hkKG",
  "token_type": "DPoP",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjI3MTdmMzAzYTI3NjVlOGFjYmY0MTEwMGFhOGE0NjllIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiZW1haWwiOiJqb2huZG9lQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImF1ZCI6InM2QmhkUmtxdDMiLCJuYW1lIjoiSm9obkRvZSIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxNzYyMTkyNTg4LCJpYXQiOjE3NjIxOTI5ODh9.V0hhdCBkb2VzIG15IHNob2VsIHNheT8gWW91IHNob3VsZCBub3Qgc2hvdw",
  "refresh_token": "8xLOxBtZp8"
}

8.4. Ping Callback

If the client has registered a deferred_client_notification_endpoint during client registration, the OP sends a Ping Callback to that endpoint once the Authentication Process has finished, regardless of the outcome.¶

The OP MUST ensure that a successful Deferred Code Exchange Response Section 5.3 containing the deferred_auth_id was sent to the RP before sending the Ping Callback.¶

Ping callbacks are not sent for timed-out Authentication Processes, since the RP is informed of any expiration time via the expires_in parameter in the successful Deferred Code Exchange Response Section 5.3.¶

The Ping Callback is an HTTP POST request containing the following parameter using the application/json format:¶

deferred_auth_id

REQUIRED: The unique identifier of the finished Authentication Process.¶

The Client MUST protect the Deferred Client Notification Endpoint from unauthorized access.¶

If the Client sent a deferred_notification_token in the Deferred Code Exchange Request, the OP MUST send the deferred_notification_token in the Authorization header as a Bearer token in order to authenticate the request. The Client SHOULD associate the deferred_notification_token with the deferred_auth_id in order to strengthen validation.¶

The following is a non-normative example of a Ping callback sent as an HTTP POST request to the Deferred Client Notification Endpoint (with line wraps within values for display purposes only).¶

POST /cb HTTP/1.1
Host: client.example.com
Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255
Content-Type: application/json

{
  "deferred_auth_id": "f4oirNBUlM"
}

The Client MUST verify the deferred_notification_token to authenticate the request if it is present. If the bearer token is invalid, the RP SHOULD respond with an HTTP 401 Unauthorized status code.¶

For valid requests, the Deferred Client Notification Endpoint SHOULD respond with an HTTP 204 No Content status code. The OP SHOULD also accept responses with HTTP 200 OK, and any HTTP body in the response SHOULD be ignored.¶

The Client MUST NOT return an HTTP 3xx status code. The OP MUST NOT follow redirects.¶

Handling of HTTP error codes in the 4xx and 5xx ranges by the OP is out of scope for this specification. Administrative action is likely to be required in these cases.¶

Clients MUST ignore unrecognized request parameters.¶

9.1. Authentication Cancellation Request

Once the RP gets possession of the deferred_auth_id from the Deferred Code Exchange Response, it can send an Authentication Cancellation Request to the OP in order to cancel the ongoing Authentication Process.¶

The Client makes an HTTP POST request to the Authentication Cancellation Endpoint by sending the following parameters using the application/x-www-form-urlencoded format:¶

deferred_auth_id

REQUIRED. The unique identifier of the Authentication Process, issued by the OP to the Client requesting the cancellation.¶

The RP MUST present a DPoP proof in this request if the Deferred Code Exchange Request included one. If the RP's Client is a Public Client, the DPoP proof MUST use the same public key used in the Deferred Code Exchange Request. Public keys SHOULD NOT be reused across different Authentication Processes.¶

The following is a non-normative example of an authentication cancellation request:¶

POST /df-authentication/cancel HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IlJTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCRnMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JEQSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJwS2piNGFEZjEiLCJodG0iOiJQT1NUIiwiaHR1IjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vZGYtYXV0aGVudGljYXRpb24vY2FuY2VsIiwiaWF0IjoxNzYzNzIzMTkwfQ.Ux89nsFXQLRKJxW5OZrOTSSQWtRAZsfB5542hICkOoOBQIOZua5US4sX7JLUqklykKSCHKeWB1FFZF4PJCmTikY9-RQPKh_rQlGFXUjnUUuAi_zatJPMh3e94EdHzHXIkUpNHV6HOTQfJZntM-eRZMGLBoFGKEiHpJlWSLWtV6pRV4GIvE8FgimNP111G_8ZSfty6K-gmIUlDZHl7LHo1GotiRuGyQOxiyqEPqV35unZiskdyIsisnA2O7nXViAD9ARuGAuM-eFlE6QJ1ji4aAPAUJnPLA0mbRhsP2DYU8YDee9tAbAkl9e45l9zhLsdEbQT07yv8zMb7zuRuczQZQ

{
  "deferred_auth_id": "SplxlOBeZQQYbYS6WxSbIA"
}

9.2. Authentication Cancellation Request Validation

The OP MUST validate the request received as follows:¶

1. Authenticate the Client in accordance with Section 9 of [OpenID.Core].¶
2. Ensure the given deferred_auth_id was issued to the authenticated Client.¶

3. If a DPoP proof was provided in the Deferred Code Exchange Request¶

   1. Validate that a DPoP proof is provided in this request.¶
   2. If the Client is a Public Client, verify that the public key used in this DPoP proof matches the one used in the Deferred Code Exchange Request.¶
4. If a DPoP proof is provided in this request, validate it in accordance with Section 4.3 of [RFC9449].¶
5. Verify that no access token has been previously issued for the Deferred Authentication.¶

After successful validation, the OP marks this Authentication Request as cancelled. Any requests to poll for the result of the Authentication Process after the OP accepts the cancellation request MUST be handled as described in Section 10.¶

Disposal of any collected Identity Information is beyond the scope of this specification.¶

9.3. Authentication Cancellation Response

The OP responds to the Authentication Cancellation Request with an HTTP 200 status code if the cancellation was successful, or if the RP submitted an invalid or already-processed deferred_auth_id.¶

Since the purpose of this request is to stop the Authentication Process, distinction of the cancellation outcome is not necessary for the RP. This behavior is similar to Section 2.2 of [RFC7009].¶

The following is a non-normative example of an authentication cancellation response:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

14.1. Interim ID Tokens

The Interim ID Token MAY contain both validated and unvalidated claims about the End User. The scheme used to distinguish validated claims from unvalidated claims is outside the scope of this specification. Options include: 1. Using the verified_claims from [OpenID4IDA]. 2. Coordination between each Client and OP to define claim names.¶

14.2. Multi-valued Response Type Authentication Request

The OP MAY accept Authentication Requests providing the response type value as deferred_code code. In those cases, it means for the OP that it MAY chose, by its own means, when the Authentication response will be of deferred type or any other provided alternative.¶

14.3. Design Considerations for Poll and Ping

The Ping Callback enables long-running Authentication Processes to occur without wasting network resources on a large amount of Poll requests. Given the asynchronous nature of the interactions introduced by Deferred Token Response, some design considerations are outlined below.¶

In case an OpenID Provider returns an authorization_pending Token Request Error Response after sending a Ping Callback, the Relying Party SHOULD keep sending Token Requests. This improves the success rates in distributed systems that may incorrectly send Ping Callbacks too early and prevents denial-of-service attacks in case the Deferred Client Notification Endpoint is compromised.¶

In certain scenarios, an RP awaiting an Authentication Process that is close to expiring may choose to perform one final Token Request slightly before the required polling interval, as close as possible to the process’s expiration time. This RP‑side strategy can help mitigate the impact of missed Ping Callbacks or authentication decisions made too late to fall within the normal polling schedule.¶

This specification intentionally does not define a way to deliver the token directly to the Client Notification Endpoint, known as push mode in CIBA. The push mode is not appropriate for long-running high-value Authentication Processes since losing the single push request would mean losing the outcome of the entire Authentication Process.¶

14.4. Context on the Progress of Incomplete Authentication Processes

OpenID Providers SHOULD include appropriate context regarding the progress of the Authentication Process when responding with a Token Request Error Response because the Authentication Process has not yet been completed. Such context SHOULD be included in the error_description field of the Token Request Error Response.¶

Appropriate context regarding the progress depends on the use case and the nature of the Authentication Process and the Identity Information. The Relying Party MAY forward the context to the End User if appropriate.¶

Examples of appropriate context regarding the progress of the Authentication Process include: 1. If the Authentication Process includes multiple steps, the step currently being performed. 2. If the OpenID Provider uses a queue system to schedule Authentication Process work, the number of Authentication Processes queued before the current one. 3. An estimate of the remaining processing time, if available.¶

The OpenID Provider MAY communicate the progress of each Authentication Process to the Relying Party in other ways. Mechanisms for doing so are outside the scope of this specification.¶

16.1. Usage of Deferred Notification Tokens

The deferred_notification_token is a bearer token that enables the OP to authenticate to the RP when sending the Ping Callback. Therefore, it is imperative that this token is protected against unauthorized access and disclosure.¶

This token SHOULD be generated following the least privilege principle, ensuring it can only be used for its intended purpose of authenticating the OP to the RP during the Ping Callback.¶

If the Client chooses not to use Deferred Notification Tokens to protect the Deferred Notification Endpoint, the Client MUST protect the endpoint in some other way. One option is to use mutual TLS.¶

A.1. Sample Use Case 1: High Risk Transaction Evaluation

An online banking application requires users to approve a high-risk transaction through a multi-step verification process. It is acceptable for this transaction to take several minutes, up to some hours to complete processing, as it may require additional security checks. It is not necessary for the user to remain actively engaged with the banking application during this time.¶

When a user initiates such a transaction, the banking application (RP) sends an Authentication Request with the deferred_code code response type to the bank's OpenID Provider (OP). While interacting with the End-user, the OP notices unusual behavior and decides to defer the Authentication Process until further verification is complete.¶

Verifying the legitimacy of the intent for such a transaction may involve contacting the user through alternative channels, performing manual reviews, or other security measures. During this time, the user is free to leave the banking application.¶

Transaction processing continues in the background as soon as an Authentication Decision is made.¶

A.2. Sample Use Case 2: Step-up identity assurance during a non-registration process

Many banking applications rely on credentials registered in person at a branch office, which involves human verification of identity documents. In many cases, those credentials are Passwords or Banking Code Cards.¶

Switching to on-line services, those credentials may not be sufficient to perform high-assurance operations. Applying for a loan or changing contact information may require a higher level of identity assurance, and for such, users should be authenticated using stronger mechanisms to prove their identity.¶

Concentrating this type of verification at the OP allows the RP to delegate the complexity of identity verification. This also allows changes in policies and identity verification methods without involving the RP.¶

OPs can require the use of Biometric data or documents to perform identity verification that complies to the Assurance Level required by the RP. Since not all data can be verified instantly, the use of deferred authentication allows the OP to take the necessary time to perform identity verification.¶

The RP requests Authentication with the deferred_code code response type, and in cases where the deferral is necessary, the OP can take the time needed to verify the identity of the user in the background. The RP can then present steps that don't demand the completion of the Authentication Process such as form filling, and notify the user when the final decision is made.¶

This allows for the RP to provide a better user experience, without forcing the user to stay on the RP site, requiring re-authentication, or other disruptive actions.¶

A.3. Sample Use Case 3: Identification Based on Physical Evidence

Many jurisdictions do not have a widespread method of digital identity verification such as an electronic ID. In these jurisdictions, a common way to do identity verification is to scan a physical identity document such as a passport or a driver's license. The scan is often supplemented with a liveness check consisting of e.g. a video recording of the End User, which is matched with a photograph on the physical identity document.¶

In many cases, automated systems can determine whether the physical identity document is authentic and whether the liveness check matches the photograph. In some cases, manual verification by a human operator is necessary. This manual verification can take a long time and may involve contacting the End User via another channel, which means that an ID Token can not immediately be returned.¶

The RP requests Authentication with the deferred_code code response type, and in cases where the deferral is necessary, the OP can manually verify the authenticity of the physical identity document and the match between the liveness check and the photograph. The RP can then continue with steps that don't demand the completion of the Authentication Process, and notify the user when the final decision is made.¶

This allows the RP to process most identity verification requests immediately while remaining compliant with regulation on automated decision making in identity verification.¶