Re-authorisation

[JamesMBligh]

One issue that has not been resolved yet is the process for re-authorisation so I'd like to put a position to the community for comment.

I would propose that re-authorisation is defined as the provisioning of a new refresh_token with the same consents as a previous authorisation but with a new expiry date. This implies that the full authorisation flow does not need to be completed.

CX are currently looking to test a cut down flow that is simpler for a customer whereby the accredited data recipient initiates a re-authorisation via a back channel call to the data holder, the data holder notifies the customer of the request, the customer logs in to the data holders existing digital channels and gives their consent to the re-authorisation and the data holder then provides a new refresh_token to the recipient. This would appear to align well to the CIBA protocol.

I am there for proposing that CIBA is removed as a supported mechanism for authorisation (as per #59 but that it is included in the profile as required to support re-authorisation.

Feedback on this position is welcome

[NationalAustraliaBank]

NAB is concerned that in order to implement the proposed solution, both DH and DR will effectively have to implement CIBA in addition to the redirect with known channel auth. This creates additional complexity on the overall solution implementation.

Another area of concern is with deteriorated CX due to unsolicited notifications from DH to customers via email/push/SMS/etc. (e.g. DH/banks should not be sending unsolicited requests to their customers). It is unclear how effective the overall re-authorisation is going to be, given that upon notification the customer will have to perform an action within a set time-frame in order for the new refresh token to be issued before the old one expires.

NAB proposes that re-authorisation happens through the DR as a brand-new authorisation, or a simplified version of the existing authorisation flow (e.g. using an identifier for correlation purposes, such as a consent ID).

[WestpacOpenBanking]

Westpac shares NAB’s concerns and endorses their re-authorisation proposal on this issue, namely:

• Having to implement CIBA as well as redirect with known channel authentication increases complexity for data recipients and data holders.
• Unsolicited re-authorisation notifications from data holders is a CX and a security concern. Additionally, Westpac recommends that notifications of this sort are sent by the Data Recipient as they are the providers of the end-service to the customer.
• To reduce overall complexity, reauthorisations should be initiated from the Data Recipient and follow a simplified version of the existing redirect with known channel authentication flow. Westpac believes, from a customer standpoint, removal of the capture customer identifier screen from the redirect with known channel authentication flow is an obvious area of improvement. We have not yet identified a way to do this without reverting to a straight redirect flow other than use of CIBA.

Therefore, we support CIBA for re-authentication with the following caveats:

• The compliance date is deferred to allow implementation by Data Holders and Data Consumers.
• Customers are notified of the need for a reauthorisation to be sent by Data Recipients rather than Data Holders.
• Language which allows for the decoupling of the expiry date of the refresh token from the expiry date of the authorisation is used.

[JamesMBligh]

In response to this feedback it is acknowledged that CIBA is a large overhead for a relatively simple use case. As a result CIBA has been removed as a supported flow.

As an alternative I am planning to propose a variant on the standard revocation and introspection endpoints that essentially allow for an extension of the expiry time of the Sharing ID that has been introduced.

This will be described in Decision Proposal 69. A placeholder has been created for this on the main standards site.

-JB-