Inconsistent JARM error responses

[nils-work]

Description

The DSB has received support queries regarding the format of JARM (JWT-Secured Authorization Response Mode) error responses. This has also been raised in the context of analysis of authentication and authorisation flow drop-off rates, and noted in a Working Group report under Key Opportunities 3 and 4:

Error Messages [standards] Improved OIDC error messaging could be implemented to assist ADRs and better align with metrics stages.

Intention and Value of Change

This issue is being raised to facilitate discussion on current conventions, issues or challenges in this area, and potentially to develop additional guidance or Standards to improve consistency if necessary.

Area Affected

Authorization Code Flow

Change Proposed / Topic for discussion

The detail below is provided to facilitate discussion around a potential convention for error responses. As an example, a Data Holder is expected to provide a JARM response returning the user to the ADR in this format:

https://client.example.com/cb?response=[JWT]

Where the decoded [JWT] payload section is expected to contain fields including, for example:

{
  "error": "access_denied",
  "error_description": "Optional error description",
  "error_uri": "(OPTIONAL) - a URI identifying a human-readable web page with information about the error"
}

error field

Values for the response JWT error field may be one of:

• invalid_request
• unauthorized_client
• access_denied
• unsupported_response_type
• invalid_scope
• server_error
• temporarily_unavailable

Current issue

There appears to be instances where non-compliant error values (not specified in the above list) are being returned by Data Holders.

Where a user has been unable to authenticate or has abandoned the authentication or authorisation flow, the most appropriate error value may be access_denied according to the description provided by RFC6749:

The resource owner or authorization server denied the request.

error_description field

The response JWT error_description field has the following description provided by RFC6749:

OPTIONAL. Human-readable ASCII [USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.

Current issue

Although the error_description field is optional, some Data Holders are providing inconsistent values such as:

• "Customer cancel"
• "Authentication was cancelled"
• "Customer cancelled the request"

Inconsistent values may not "assist the client developer in understanding the error that occurred".

error_uri field

As a way to provide consistency in understanding the reason and potentially the stage of drop-offs in the user journey, there was a suggestion that a standardised set of values or a URN format could be developed to provide better insight in this area.

An option may be to provide consistent values in the error_uri field. Potential values may include:

• urn:au-cds:auth-error:user/abandon/preIdentification
• urn:au-cds:auth-error:user/abandon/preAuthentication
• urn:au-cds:auth-error:user/abandon/preAccountSelection
• urn:au-cds:auth-error:user/abandon/preAuthorisation
• urn:au-cds:auth-error:user/abandon/rejected

Questions for participants:

• Would the example values above provide useful feedback?
• Would less granular details suffice?
• Are additional values required?
• What challenges may there be in implementing and gaining insight from these?