Decision Proposal 099 - Concurrent Consent Target State

[Technical-DSB]

Thank you to everyone for your feedback. This consultation provided good contribution from participants and provided important feedback now and into future aspects of the standards.

The final decision document has been reviewed and approved by the Data Standards Chair. It is attached here: Decision 99 - Concurrent Consent.pdf

---

The prior decision proposal consulted on is available here.

Previous consultation:

This decision proposal continues the consultation on the target state solution for concurrent consent in the standards. It is a continuation of the consultation on Decision Proposal 085.

A proposal document has not been created for this decision as no specific recommendation has been identified by the DSB. Instead the context will be outlined below and the suggested solutions that have previously been proposed by the community will be listed. The intent is that a specific proposal will be generated from this consultation and put to the community for further feedback.

Context
In Decision Proposal 085 a change was made to the standards to prepare a path for concurrent consents but that restricted the initial implementation for July 2020 to single extant consent to minimise implementation impact. This decision also proposed a target state to be implemented in the November 2020 timeframe. This target state solution included the passing of an active refresh token via the front channel to the authorize end point. Security concerns have been raised with this approach.

The Ask
This consultation is therefore being initiated to identify feasible solutions to the original problem statement articulated in Decision Proposal 085 that will:

• Be adequately secure
• Allow ADRs to communicate that a new consent is a replacement for an existing consent
• Ensure that the establishment of the new consent and the revocation of the existing consent is atomic
• Provides a technical position that will be inhibit future sectors and future use cases

Options Identified To Date
Staged Intent
The FAPI staged intent pattern could be used to stage consent, this would result in a separate intent ID that could be used to refer to a previous consent and would also mean that any sensitive content related to consent is only conveyed server to server.

Pushed Request Object
The FAPI pushed request object pattern could be used to stage a complex or sensitive request object. This would be light impact to the standards but would allow for sensitive content related to consent to be only conveyed server to server.

Encrypt Existing Refresh Token
The 'existing_refresh_token' claim could be encrypted in the request object.

Addition Of A Sharing ID
Introduce the concept of a 'sharing_id' claim that would be issued when a new consent is established that is not a token (and therefore secret) but can be used to identify an existing consent for replacement or revocation purposes.

Status Quo
The real risk of passing the refresh token is clarified as being immaterial considering other controls established in the information security profile, such as the usage of client authentication, MTLS and HoK for the token end point. In this case the current, documented target state may be considered valid.

[SachiniSiriwardene]

Out of all the given options, I think the sharing id claim is a more clean and safer way to solve the issue. When a consumer successfully authorizes the consent, the sharing_id claim can be sent in the Id token to the DR.
If the DR wants to revoke an earlier consent, the sharing_id of the consent to be revoked can be sent in the request object. If no consents are to be revoked, no sharing_id should be sent.

[anzbankau]

We support the addition of a sharing ID to fulfill this functionality, as it is a minor modification from the existing implementation and prevents exposure of the refresh token to the customer’s device.

[WestpacOpenBanking]

It is important that the chosen solution approach will allow for appropriate levels of extensibility as the consumer data right regime continues to evolve. Most acutely, the CX stream has flagged that investigation into re-authorisation will occur in the next few months, including investigation into simplification of the flow during re-authorisation, and amending of the consent during this process. Research into joint accounts and fine-grained control have also been flagged as part of the same body of work. Longer term, it is reasonable to expect development of the rules with complex multi-party consents, intermediaries and write access being among the possible additions to the regime.

Most solution options presented do not have the extensibility required to adapt to expected changes over time with minimal ongoing implementation complexity or forcing expensive customizations to vendor supplied IAM software.

Although infeasible for November timeframes, we recommend that a consent object type approach be adopted over time and remark that the FAPI staged intent proposal or the UK open banking approach are suitable starting points for development. Previously articulated benefits of an approach of this type include:

1. Extensibility in terms of the information exchanged in the consent process. Including for example indicating mandatory and optional data clusters or the historical extent of transactions (fine grained consent)
2. Ability of data recipients to enquire on the status of an in-progress authorisation. This allows more robust recovery in error scenarios
3. Extensibility in terms of the ability of data recipients to obtain richer status information (e.g. reason for revocation or an error status)
4. Some types of user-facing error being avoidable entirely (because a back channel exchange happens prior to the consent flow)
5. Decoupling of refresh token lifecycle from sharing arrangement lifecycle.
6. Increased security and lower implementation cost by decoupling security and business concerns minimizing customization of vendor supplied IAM solutions.
7. Avoidance of customisation of security infrastructure reducing implementation costs and reducing the risk of security vulnerabilities
8. Avoidance of browser compatibility issues because of large request objects
9. Ability of data holder to know if a data recipient is retrying a previous request or starting a new request.

A key difference between these approaches is the method of exchanging the intent/sharing identifier. In the FAPI staged intent proposal dynamic scopes are used, whereas in the UK open banking approach a claim is used (similar to the Addition Of A Sharing ID option). Vendor support for either of these methods will need to be considered as will the difficulty of transition from the current state of the standards for participants.

The UK approach gives extensible and secure patterns allowing for querying, deletion and sending of notifications (e.g. for revocation, addition or removal of accounts and so on). These are not incompatible with the proposed FAPI intent pattern. There are likely security benefits to adopting similar approaches. The data recipient to data holder interaction pattern in particular is based on standard OAuth patterns which are the subject of substantial international research. Additionally, a revocation notification using this pattern would not involve the transmission of sensitive refresh tokens, and updates are better protected by defence in depth:

1. Australia:
   a. Refresh token / ID must be valid
   b. JWT signature must be valid
2. UK
   a. Refresh token / ID must be valid
   b. JWT signature must be valid
   c. TLS-MA must be established
   d. + The rest of the DR->DH security

We are happy to collaborate further on an intermediate state proposal and suggest that a workshop may be a productive approach to create a proposal for consultation.

We remark that options involving the sharing of refresh tokens (unencrypted or encrypted with an un-established pattern) carry security risks and we strongly recommend removing the existing mandate to adopt an approach of this type for November.

[commbankoss]

Commonwealth Bank agrees with @WestpacOpenBanking (#99 (comment)) that target state consent solution should solve for fine-grain authorisation, re-authorisation, multi-party consents as well as improvement of the security of the ecosystem.

Options identified in the original post above: (#99 (comment)) can only be used as a partial solution.

E.g.

• “Staged Intent” and “Push Request Object” deal with authorisation request delivery.
• “Encrypt Existing Refresh Token” and “Addition of a Sharing ID” deal with a security concern with current approach to re-authorisation.

Support for fine-grain authorisation, multi-party consents and etc. require additional building blocks.

We welcome a suggestion of a collaborative workshop with industry participants to discuss and agree on a solution to satisfy current and future consent requirements.

[sakimura]

My name is Nat Sakimura and I am the Chairman of the OpenID Foundation (OIDF) and am one of the Chairs of the Financial-grade API Working Group (FAPI WG).

The OpenID Foundation is a non-profit international standardisation organisation of individuals and companies committed to enabling, promoting and protecting OpenID technologies. The Financial-grade API Working Group is dedicated to the development of technology standards suitable for use within the financial services landscape. Active members include technical implementers within the UK Open Banking ecosystem as well as emerging open banking initiatives including Australia, USA, Canada, Germany, South Africa, Canada and Brazil. Multiple standards have been established within this working group including the ubiquitous FAPI R/RW specifications and many lessons learned and shared by our members.

For more than a year, the FAPI WG has been in active discussions among its members as the Australian Consumer Data Right evolution has occurred. More recently the FAPI WG has conducted detailed design and architecture discussions to provide a proposal for a flexible model for establishing, maintaining and withdrawing consent. This specification has included all of the requirements from our members and incorporated lessons learned from our shared experiences of implementing various complex consent sharing mechanisms including the Lodging Intent specification used within Open Banking UK and other market initiatives.

After a detailed analysis of the problem space, it is clear to FAPI WG members that any solution must be flexible enough to allow for jurisdictional requirements whilst facilitating data minimisation principles. It is also clear that the definition of “consent” has both legal and variable interpretations across jurisdictions. Due to this ambiguity, FAPI WG members prefer instead to utilise the term “grant” to provide an unambiguous description to a solution designed to cross multiple jurisdictional (ie. legal) boundaries. Any proposed model must also be flexible enough to facilitate new requirements introduced post-implementation.

We attach a presentation which seeks to define the problem space, evaluate the existing approach the CDR has taken to consent and provide a proposal which leverages a number working group work items which meet the long term objectives of the CDR ecosystem.

In summary, the FAPI WG proposes the implementation of the following combination of specifications:

• Pushed Authorisation Request: A draft specification for the submission of large request objects via a backchannel endpoint
• Rich Authorisation Request: A draft specification to enable rich and flexible metadata to be passed within the Request Object. This specification allows for a standardisation of the request object container while retaining metadata flexibility for jurisdictional customisation
• Grant Management API: An emerging OAuth2 extension to facilitate the creation, renewal, discovery, status, deletion and optional update & suspension of grants including for complex use cases such as joint accounts, intermediary and delegated authority environments.

While some Australian requirements are unique, the problem is not. Let’s solve it together for the benefit of the customers in multiple jurisdictions. We believe Australia has an opportunity to become a world-leading technology reference case for other worldwide data initiatives and we welcome the opportunity for further and hopefully fruitful collaboration.
Consent proposal for CDR (Australia).pdf

[NationalAustraliaBank]

NAB supports the option for the inclusion of a sharing id claim to replace the current “existing_refresh_token” mechanism.

[cdradr]

We agree with full re-design of consent, addition of sharing ID and consent API.

Concurrent consents might be required or not.

Accounts should be a part of consent to make it useful for ADRs.

[Technical-DSB]

The period of feedback for this consultation is now closed. Thank you to everyone for your contributions. As stated, the next step for this issue will be the development of a specific proposal that will be posted in a separate thread for further consultation before a recommendation is made to the Chair.

It should be noted that some of the feedback was outside of the scope of the initial issue. This feedback has been noted but will not be reflected in the proposal that will remain targeted at The Ask outlined in the main issue description.