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.

_errordescription field

The response JWT _errordescription 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 _errordescription 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".

_erroruri 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 _erroruri 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?

[markskript]

Skript strongly supports this change as an alternate approach to this change. Implementation would provide greater visibility into consent dropoffs for the ADRs and would allow us to provide tailored support to consumers once they are redirected back to the ADR-side of the consent flow.

The above suggested values seem to align to the v5 GetMetrics which makes sense to us also.

Also noting that some DH's are not passing back a JARM at all in this scenario currently - so ideally that would also be resolved at the time of implementing this change.

[TT-Frollo]

Frollo also strongly supports this change. The example values are very useful. Whilst there is no value specific to post authentication (OTP success) we could assume that a pre account selection abandon means successful authentication, although this is doubling up. Also, it would be good to align the Cx guidelines/standards to address the issue where customer abandons are due to difficulties getting through the flow and not siply a chnage of mind to complete the authorisation.