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?

[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.

[joshuanicholson]

SISS would like to support this suggestion fully.

[nils-work]

Discussion on this issue in the MI call today included:

• Some Data Holders are not providing compliant JARM error responses, meaning Data Recipients have trouble explaining problems the consumer has encountered in the Data Holder authorisation process.
• Consistent responses aligned to the abandonment Metrics requirements would help Recipients in providing contextual support to consumers when issues occur.
• The issues that occur may be:
  • Pre-authentication (related to customer identifier or OTP)
  • Post-authentication (for example, related to account availability or Nominated Representative status)
  • Post-authentication issues may fall into two groups
    • Authorisation cannot continue at all (for example; due to not being a Nominated Representative, the consumer cannot proceed).
    • Authorisation can continue with some accounts but not all (for example, not being a Representative for all accounts, or entitlements for some accounts not aligned to CDR in some other way.)
• Whether Data Holders could be required to include support options for Consumers to indicate that they had a certain type of problem or concern in the authorisation flow (for example, some or all accounts unavailable).
• Whether a type of 'support identifier' that could be shared between the ADR, Consumer, and Data Holder would assist with troubleshooting errors in the above scenarios.
  • If a support identifier was considered valuable, which standards would it rely on, and for how long would a Data Holder need to keep records of unsuccessful authorisation attempts for troubleshooting purposes.
• There is support on the Recipient side for the change proposed (more granular error detail and greater compliance).

[perlboy]

Based on the guidance here: https://cdr-support.zendesk.com/hc/en-us/articles/8485633822735-Get-Metrics-V5-abandonment-by-stages

This method will only capture active denial by the user-agent. App or Window closures will be lost as will user-agent's which never arrive at the consent flow and user-agents which fail to return from authorisation flow after the final Authorise step. It also means failed token exchange is entirely out of scope. Further the guidance is that "Exit is furthest stage reached" which will likely result in false metrics and confusing error reports between ADRs and Holders for situations where the user has gone back. While I understand and support the objective of this proposal, it is papering over the cracks of a brittle arrangement establishment process and I doubt will result in the size of benefit ADRs believe it will.

On this note DataRight+ recently published a draft Sharing Arrangement V2 specification which not only seeks to align with the intent based pattern originally adopted by the UK Open Banking scheme, standardising Australia to the global norm, but provides explicit capability to poll consent status by treating an arrangement as a first class resource.

My fear here is that when it is all said and done the ecosystem will spend the better part of 2025 continuing to tread water by patching over issues rather than leaning into and properly solving the underlying problems in a sustainable way, notably, the explicit separation of concerns between arrangement/agreement state and oauth2 authorisation. These are the same problems for which solutions must be found once actions broader than just sharing are in scope.

[markskript]

My fear here is that when it is all said and done the ecosystem will spend the better part of 2025 continuing to tread water by patching over issues rather than leaning into and properly solving the underlying problems in a sustainable way, notably, the explicit separation of concerns between arrangement/agreement state and oauth2 authorisation. These are the same problems for which solutions must be found once actions broader than just sharing are in scope.

With that view - I assume Addition of a DH-side endpoint for querying the status of a consent establishment flow would be closer to your preferred approach?

#628, or something like that, would be our preferred approach as well, but it comes back to the cost/benefit analysis. The end goal here is to allow ADRs to better support consumers who are having trouble with the consent process. Right now, we have some DHs that don't pass back a JARM at all (a compliance issue really). The DHs that do pass back a JARM, the information they contain is not useful. I believe the thinking is to improve the JARMs with this "small" change while we look at a proper solution in #628 if we feel that consent dropoff rates aren't improving.

If improvements are made in other areas, such as the Nominated Rep rules, then I expect those would have a big effect on drop-off rates as well and may make changes like #628 not worth the effort.

Can DHs comment on whether this #649 change - updating the JARMs with some more context - is feasible to allow the DSB to gather some intel on the cost/benefit?

M.

[CDR-CX-Stream]

Discussion on this issue in the MI call October 2 included:

• One data holder noted they are currently implementing a ‘Cancel’ button so the consumer can return to the ADR. They indicated for security reasons they sometimes do not provide error feedback, but data holders are required to provide a compliant response (either error or success) in all cases when the user is returned by redirect to the ADR.
• DSB mentioned possibly making a ‘cancel’ button mandatory
• Action: Data holders to provide views on whether they provide a 'cancel' button, and whether it should be mandatory to do so

[CDR-CX-Stream]

Following further discussion and analysis, we invite feedback on the value of data holder standards to:

• provide a clear and consistent way to cancel authentication and authorisation
• request that consumers confirm that they wish to cancel and exit the flow
• capture and report the screen on which the user left the authentication or authorisation flow and provide the stage detail to the data recipient through the error response. This would occur regardless of which link or button the user interacted with to leave the flow, provided it is in control of the data holder.
• optionally provide a survey for consumers to voluntarily complete when cancelling or exiting the flow, for the purpose of collecting data on the reasons for cancellation

[markverstege]

If we provide specific error codes on the JARM response, wouldn't we be overriding the oAuth specs which may be problematic for Data Holders configuring IAM vendor products? Good error handling can improve interoperability, but with the scenarios above, there would still be scenarios where the ADR doesn't receive an error response (e.g. the browser is closed). An alternative to this approach is a lodged-intent approach adopted by the UK. Having a mechanism for the ADR to stage their intended consent request (and the intended actions they are about to perform one one or more resources), a lodged-intent API could receive the request, and provide approrpriate error responses without overriding oAuth error response handling. In this scenario, a lodgement identifier could be provided to the ADR for sending in the authorisation request. Through a lodgement query API the ADR could collect the status of the lodged "job" and obtain any data/resource-layer error reporting.

Alternatively, approaching this using RAR and the Grant Management API could be another option?

[CDR-CX-Stream]

This issue was discussed on the October 30 MI call where the community provided their views on DSB's recent comment. The following views were provided:

• ADR participants suggested that the standardisation approach (i.e. error codes in JARM responses) might be a quick win and would want to hear DHs views on it. The cost/benefit of better solutions might not stack up, and some structured field data will give them something.
• A CDR vendor noted their observations that some DHs struggle to provide appropriate error codes during the consent flow and suggested that standardising error codes via JARM would not work. It was hypothesised it might be easier for DHs to implement error codes outside the consent flow, which would involve a Job ID which could be used to poll the status of a consent. This would de-couple it from JARM and response modes.
• ADR participants reiterated they just want to know where the failure is to provide better support for the consumer, as not receiving an OTP is much different to leaving at account selection, or abandoning at the end of the consent flow.
• CDR vendor reminded everyone that explicit errors won’t solve someone closing the browser. Only 50% of the problems would be recorded with either solution.

ACTION: Data Holders and ADRs to provide feedback on the above views discussed during the call.

[CDR-CX-Stream]

As part of the CR discussion, there was a suggestion to create CX Standards for data holders that would provide consumers with a clear, consistent way to cancel authentication and authorisation and offer interventions to collect error information that could be passed on to ADRs. Due to limited input on this matter, the CX team will conduct further analysis on these proposals alongside other consent drop-off issues.