Decision Proposal 099 - Concurrent Consent Target State

[CDR-API-Stream]

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 (https://github.com/ConsumerDataStandardsAustralia/standards/issues/99#issuecomment-587993724) 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: (https://github.com/ConsumerDataStandardsAustralia/standards/issues/99#issue-559369359) 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.

[CDR-API-Stream]

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.

[CDR-API-Stream]

Hi everyone, thanks for your feedback. Based on the feedback raised by the community, changes have been incorporated into an updated decision proposal for concurrent consent.

This decision proposal outlines a recommendation for enabling concurrent, or overlapping, consents under the CDR regime.

The consultation draft for this decision proposal is attached below: Decision Proposal 099 - Concurrent Consent.pdf

Feedback is now open for this proposal. Feedback is planned to be closed on the 9th of April 2020.

[RalphBragg]

General Comment:

Thanks for the proposal – It is great to see new standards being considered to address some of the challenges that the community has raised. A lot of inspiration appears to have come from the FAPI 2.0 draft which is available for review and all comments welcome.

It would be great for global interoperability if Data61 / CSIRO could cross reference Proposal 99 against the FAPI 2.0 spec and provide a profile that clearly calls out the differences. This would simplify implementation challenges for vendors, banks and the security community alike.

It looks as if vendors and banks support FAPI 2.0 then they will have all of the necessary RFC support to implement Proposal 99.

Conveying Sharing ID / Requiring PAR

Introducing a consent management API, ala Open Banking UK is a proven well adopted pattern, as it’s essentially lodging intent with an ID being returned. Is the intention or direction of travel to extend this API to incorporate fine grained consent and if so, has RAR (Rich Authorization Request) been considered?

This is then posted using PAR with justifications for PAR adoption given around security and payload size which I hope you can answer the following questions.

1. Security Comment: Enumeration Raidiam considers the enumeration attack to swap or change a sharing_id with another valid one as minimal vs the overhead of requiring PAR in the timescales suggested.

2. Security Alternative: JAR (signed) If this really is deemed to be a significant security issue then JAR or encrypted JAR would mitigate this issue alone which is far more likely to be supportable by vendors as they have similar capability from the OIDC Request Object by Reference and the requirement for its use in FAPI 1.0 today.

3. Size Comment

Decision 99, uses a Size justification for requiring PAR however the inclusion of a sharing ID will not materially increase the payload size. For example, the UK ecosystem functions perfectly well with the inclusion of sharing ID in the front channel request. PAR is really only required on a size justification if a RAR is also going to be used.

4. Hybrid Flow Requirement vs PKCE

If PAR is adopted why is OIDC hybrid still being used instead of just moving to supporting PKCE RFC7636? If the ecosystem is considering such a fundamental change then aligning to FAPI 2.0 or baselining the profile requirements against this specification might be useful.

5. PAR adoption implementation timescale challenge Given that this proposal is mostly the “lodging intent pattern” there are standards adopted in market that could achieve the objective that are already vendor supported have data holders expressed any concerns about adoption of PAR in the timescales?

As we understood, the security challenge detailed in issue 74 was raising concerns about the passing of a credential via an untrusted network segment but this appears to being used to justify not putting anything through the front channel. This proposal removes the requirement to share a credential via the front channel and so derisks the security issues with the front channel. Espeically if JAR is adopted. Are there any ecosystem concerns about the ability for the Data Holders and Data recipients to uplift and implement this standard in the timeline outlined

Final Comment: Generally, Raidiam is fully supportive of using RAR,PAR,JAR if fine grained sharing is in scope, which it isn’t with this proposal. Currently it appears to be a very similar model to what is currently used by the UK OBIE and as such it would be useful if Data61 could share their decision making process that led to the requirement for the ecosystem and their vendors to uplift to PAR for this need alone?

Perhaps if Data61 / CSIRO would signal the intention to move to RAR instead of a sharing API then requiring banks make this uplift to support PAR now so that they can support RAR in the future would be much easier to justify for the ecosystem.

Technically, Raidiam's OpenID Provider already implements all of the required RFCs and standards required by Decision 99 and so we can support any standards based solution that the ecosystem adopts. Commentary from other vendors would be welcome.

[mark-nienaber]

With respect to the following comment made by @RalphBragg

It would be great for global interoperability if Data61 / CSIRO could cross reference Proposal 99 against the FAPI 2.0 spec and provide a profile that clearly calls out the differences. This would simplify implementation challenges for vendors, banks and the security community alike.

It looks as if vendors and banks support FAPI 2.0 then they will have all of the necessary RFC support to implement Proposal 99.

I agree that a comparison of FAPI 2.0 and Proposal 99 would be helpful for relevant parties to clearly understand compliance or implementation challenges.

[mark-nienaber]

With respect to the following comment made by @RalphBragg

Hybrid Flow Requirement vs PKCE If PAR is adopted why is OIDC hybrid still being used instead of just moving to supporting PKCE RFC7636?

Agree on the consideration of the use of Auth Code + PKCE. While commonly considered only for SPA's has become the industry best practice to use wherever possible.

[anzbankau]

ANZ views many of the changes in the latest decision proposal as beneficial, but would like to note that most are not required to achieve the capability of concurrent consents.

Please see below for aspects we support and some items to further refine:

• We are supportive of the addition of PAR and JAR.
• We do not support the addition of the Sharing Agreement Management API as there seems little beneficial functionality from this at this point.
• We note that the proposal states that Data Holders should support request object by value as well as by reference. We would prefer to have a consistent mechanism, especially given using PAR is beneficial from a security perspective.
• As we have mentioned we are not supportive of the Sharing Agreement Management API, this feedback also applies from a Data Recipient point of view. I.e. we see minimal benefit in ADRs having to implement this and it adds complexity if both mechanisms (i.e. revoke end point and Sharing Agreement Management API) are supported.
• We would recommend adding MTLS on the PAR API integration between ADR and ADH.

Furthermore, we would like more specificity for:

• When the ADR can call the authorization end point using sharing_id?
  • Is it within a certain time period before expiry?
  • Can the consent be extended multiple times? (e.g. within a single day, so that the expiry is greater than 12 months)
  • If so, what is the maximum expiry of the consent?
  • How frequently can this be called?
• RecipientBaseURI is added to the SSA, but should it also be added to the registry?

[WestpacOpenBanking]

As we have previously articulated, long term we believe that the regime should move towards an approach along the lines of the FAPI staged intent proposal or the similar UK Open Banking approach, ideally after flagged CX work is completed. Introducing a sharing_id claim and the Sharing Agreement Management API are both positive steps in this direction and overall we welcome the proposal as an improvement over the approach which has previously been articulated. We agree that the proposal addresses the key concerns and moves towards a technical position that will facilitate future sectors and use cases.

However, we are unable to support the use of Pushed Authorization Requests in the near future. The proposal is still in draft format and our vendors are unlikely to support this functionality in November timeframes. Sufficient availability of certified platforms and libraries is important to ensure security and to control implementation cost and complexity for all participants.

We also suggest the removal of direct references to the JAR draft standard. We are concerned that the inclusion of these references may cause confusion because JAR specification is targeted at hosting request objects at endpoints controlled by the client whereas the PAR draft standard is focussed on pushing request object to the authorisation server. Additionally, the immediate benefits of allowing a third method of passing a request for authentication are unclear. Finally, we are also concerned that client hosting of request objects may be less secure. A more thorough analysis would need to be undertaken to ensure that any risks are identified and adequately controlled – it is unlikely that this could occur and leave enough time for November implementation.

In relation to proposed changes to standards we have the following feedback:

• In the Request Object section, Client hosted request objects by reference should not be supported. We suggest: “Request Object references SHALL NOT be supported in any mode of use other than Pushed Authorisation Requests (PAR). If a Data Holder does not support Pushed Authorisation Requests (PAR), it MUST NOT support Request Object references.”.
• In the Revocation Endpoint section we suggest the addition of a statement to say that the use of the Data Holder’s revocation endpoint for the purposes of revoking consent is deprecated in favour of using the Data Holder’s Sharing Agreement Management API.
• In the Sharing Identifier section:
  • It should be clarified that the sharing_id must not be provided where an ID Token is provided from the Authorisation endpoint.
  • We recommend removing the examples as the reason for inclusion is unclear. We also remark that there are references to sector_identifier but this is not part of the standard as far as we are aware.
• In the Supporting Pushed Authorisation Requests by reference section:
  • We believe that it should be made clear that that the Data Holders should not support JAR in any other mode than PAR (as per our feedback above).
  • MTLS should be used on the pushed_authentication_request as per the PAR draft standard which states that the same authentication method is used as at the token endpoint.
  • The term “authorisation tokens” should be defined or accepted terminology (e.g. ‘refresh token’ and/or ‘access token’) should be used.
  • Regarding the statement, “If the sharing_id is not related to the consumer being authenticated it MUST be rejected". The consumer is not known at this point in time. This rule will need to be moved to elsewhere in the standard.
  • Regarding the statement, “Data Recipients MAY provide an existing sharing_id as a hint in an authorisation request object”. The use of the word ‘MAY’ and ‘hint’ are incorrect here. The Data Recipient MUST add this claim if this request is to invalidate previous tokens under this sharing_id. Additional it is a claim, not a hint, as the Authorisation Server is not free to ignore this value.
  • Regarding the statement, “Data Holders MUST revoke existing authorisation tokens and consents when a sharing_id is provided as a hint in the authorisation request object”. There is a need to add clarifying text to say existing authorisation tokens and consents associated with this sharing_id are to be revoked.
  • Regarding the statement, “Data Holders MUST revoke existing authorisation tokens and consents when a sharing_id is provided as a hint in the authorisation request object”. Does this mean that existing authorisation tokens and consents should be immediately revoked, rather than waiting for a successful authorisation?
• In the Sharing Agreement Management API and Consent Revocation section:
  • Regarding the statement, “Data Recipients MUST publish their Sharing Agreement Management API under their InfoSecBaseURI published in the CDR Register". This statement seems to contradict the statement made earlier in this decision proposal that the Sharing Agreement Management API allows the separation of business concerns and security concerns. This, however, is likely to be an error – on page 15, a contradictory statement is made: “Data Recipients MUST publish their Sharing Agreement Management API under the ResourceBaseURI that is published on the CDR Register.”
  • Regarding the statement, “Data Recipients MAY deprecate support of the revocation endpoint. This MUST be inferred through the absence of the revocation_endpoint in the Data Recipients SSA.” The use of the word deprecate is incorrect here. Data Recipients would be ceasing (not deprecating) support for revocation through the revocation endpoint if the revocation endpoint ceased to be published in their SSA. The implied outcome of this statement and the following statement, “The Data Recipient’s Revocation endpoint MUST ONLY revoke authorisation tokens”. We note that despite any compliance dates, in order for the system to continue functioning, Data Recipients could not update to the new method until all Data Holders had completed their updates.
• The Refresh Token management section seems to be incomplete. In particular:
  • It does not explain the expected behaviour if the Data Recipient fails to obtain a new Refresh Token before the expiry of the current one. In this scenario, the consent has functionally expired as there is no way for a Data Recipient to obtain a new access token. Recommend that if the intent is that the Data Recipient is meant to be able to reauthorise the consent within the current sharing_duration then this is explicitly stated.
  • Regarding the statement, “oAuth Token Revocation endpoints MUST only be used for the purposes of token management”. The operation of this regarding Data Recipients who have not been upgraded is not specified. We think that there is a need to provide well-articulated description of the transition plan in each of the four scenarios:
    • Old DR calls new DH
    • New DR calls old DH
    • New DR calls new DH
    • Old DR calls old DH

[CDR-API-Stream]

Hi @RalphBragg and @mark-nienaber, thanks for the comments. A reminder to the community that consultation on this Decision Proposal closes today. Any feedback should be provided by COB 9th April.

To address the points raised so far: Cross reference Proposal 99 against the FAPI 2.0 spec From a standards perspective, the CDR concurrent consent proposal in addition to CDR data standards would support all standards referenced in the FAPI 2.0 Profile other than:

• RFC7636 (PKCE)
• Rich Authorization Requests (RAR)

1. Security Comment: Enumeration @RalphBragg could you please expand further? I assume these comments are related to your later comments on PKCE support?

2. Security Alternative: JAR (signed) This is under consideration.

3. Size Comment That is not the only justification for PAR and specifically achieving staged intent using request object by reference. It is a consideration and a known limitation as we move towards a richer authorisation model - consideration was given to future implementation burden on the ecosystem vs building core foundations that will reduce implementation burden in the future.

4. Hybrid Flow Requirement vs PKCE This wasn't part of the scope for concurrent consent and has not been raised by previously by the community under the concurrent consent consultation.

That said, FAPI 2.0 is under consideration and we will consider how this fits into the data standards roadmap in consultation with participants. As consultation on the third banking maintenance iteration has commenced we would welcome feedback from the community on their priority views under DP 108.

5. PAR adoption implementation timescale challenge Thank you for this @RalphBragg. We'd welcome feedback from IAM vendors on their current supportability of PAR. The DSB recognises that the OIDF had provided recommendations on consideration and adoption of PAR previously in this consultation.

Feedback is always welcome regarding implementation impacts and are considered seriously and the DSB recognises that the OIDF had provided recommendations on consideration and adoption of PAR previously in this consultation. We have accommodated this feedback in the timeframes for adoption of the standard and made allowance for phased implementation in the approach we have recommended.

6. Re:Issue # 74 Moving towards standards adoption of PAR and request objects by reference is also designed to more easily facilitate fine-grained authorisation in the future if it comes into scope as well as the inclusion of sensitive information in the request if that eventuates also.

7. Final comments Draft standards such as JAR, RAR, PAR and emerging draft standards such as Grant Management API will continue to be monitored and will be considered in the future as regime requirements bring them into scope.

PKCE Adoption Thanks @mark-nienaber and @RalphBragg. We recognise that industry guidance now considers PKCE as the preferred flow vs Hybrid Flow. This will be considered in future consultation with the community.

[SlatsFR]

ForgeRock is engaged with the development and ratification of the FAPI2 security profile and the technologies by which it is underpinned. To provide an overview of where the Security Profile stands from a ForgeRock perspective today, included below is an overview of current status of development and support for the aforementioned technologies:

OAuth 2.0 Authorization Framework [@!RFC6749] - Fully Compliant OAuth 2.0 Bearer Tokens [@!RFC6750] - Fully Compliant OAuth 2.0 PKCE [@!RFC7636] - Fully Compliant OAuth 2.0 Mutual-TLS Client Authentication [@!RFC8705] - Fully Compliant OAuth 2.0 Pushed Authorization Requests (PAR) [@!I-D.lodderstedt-oauth-par] - *RFE in progress* OAuth 2.0 Rich Authorization Requests (RAR) [@!I-D.lodderstedt-oauth-rar] - RFE in progress OAuth 2.0 Authorization Server Metadata [@!RFC8414] - Fully Compliant OpenID Connect Core 1.0 incorporating errata set 1 [@!OpenID] - Fully Compliant**

• *With regard to:

  • PAR (https://bugster.forgerock.org/jira/browse/AME-19533)
  • RAR (https://bugster.forgerock.org/jira/browse/AME-19534)

Request For Enhancements have been created and their priority set to 'Major'. As such, they are viewed by our Product Management team, as well as our various working group members, as proceeding on a trajectory making them likely to be adopted globally. That said, we are still in holding pattern as the specifications are still stabilising. Until the specifications are ratified, it is not possible for vendors to bring a complete solution for the technologies to market.

ForgeRock encourages the continued leveraging of standards by the working group wherever possible, while making allowances where the standard driving the preferred solution is incomplete.

[commbankoss]

Business Feedback

Commonwealth Bank continues to support the introduction of concurrent consent, and believes the proposal requires the following:

• Guidelines for Data Recipients to avoid inconsistent or confusing customer experiences (e.g. multiple consents on a consent dashboard without the ability to differentiate them, multiple CDR receipts etc). We recommend further testing from Data61 CX stream to assess impact on consumers.

• Consent purpose to be communicated from Data Recipient to Data Holder. As we have done previously, Commonwealth Bank continues to recommend the inclusion of consent purpose to make it easier for the end user to differentiate between different consents. If CDR adopts RAR, this would allow purpose to be added with minimal effort and no custom extensions.

Technical Feedback

Commonwealth Bank welcomes the introduction of Consent back-channel lodgement pattern (PAR), Consent API (Sharing Management API), and consent ID (sharing ID), that UK has adopted and we have previously advocated for.

Commonwealth Bank prefers a solution that:

• Reduces the build impact once fine-grain consent or multi-party consent are introduced.

• Drives alignment to the target state described by:

  • Westpac

  • Commonwealth Bank

  • OpenID Foundation

• Maximises the alignment to open standards (PAR, RAR, Grant Management and FAPI 2, in general). Adoption of Grant Management specification instead of Sharing Agreement management API would improve security, increase chances of vendor support, and minimise long term implementation costs.

• Doesn't require Data Recipients to host Sharing Management / Grant Management APIs which is an additional cost and complexity imposed on Data Recipients. We believe that consent revocation notification (from Data Holder to Data Recipient) can be solved differently (e.g. OBIE UK's event notification specification or bulk consent event API). This will also address security and availability concerns raised around current implementation of Data Recipient's consent / revocation (client authentication and exception processing).

Implementation Staging

If staging is required, we agree that PAR and re-authorisation (CIBA) can be deferred. RAR and Grant Management are more essential for setting us up for the consent target state.

Commonwealth Bank believes that the introduction of JAR in as part of the November release does not deliver additional benefits to the ecosystem, as signed request objects are already used by the CDR.

Transition

Lastly, Commonwealth Bank believes the migration strategy from consents established after the initial go-live, to the consent framework to be established after the release of concurrent consent, should be outlined. Commonwealth Bank recommends this strategy should minimise transition effort.

[mperryau]

Ping is strongly in favour of a solution for concurrent (and in the future, fine-grained) consent built on open standards. We have been vocal in past discussions in this forum, and as a member of the Advisory Committee for the Data Standards Body, about the need to remain consistent with InfoSec open standards. Designing bespoke security standards just for Australia makes it more difficult and more costly for Data Holders, Data Recipients, solution vendors, and solution implementers to implement and maintain a compliant solution.

We support aspects of the current form of this proposal, but recommend it more closely resemble that submitted by the OpenID Foundation (OIDF), as detailed in the previous response from @sakimura. As a member of the OIDF and the FAPI working group, Ping collaborated in the development of this design. Brian Campbell, Distinguished Engineer at Ping Identity, is also a co-author of RAR, PAR, CIBA, RFC 8705, RFC 7523 and other related standards.

We also recommend that the implementation of this proposal be delayed, to allow for detailed workshops between Data61, the OIDF and other industry participants. This mechanism will form the basis of fine-grained authorisation for the CDR, across banking, energy, telco and other industry segments, and it’s our belief that it needs to be designed with due care rather than meeting an arbitrary timeline.

In particular:

• We agree with the implementation of PAR
• We agree with the implementation of JAR, but only with respect to what PAR requires (i.e. the request_uri parameter)
• We are supportive of RAR being included but caution that its inclusion has a greater impact on the specification than PAR and JAR, and as such needs more time for the industry to evaluate its impact
• We reiterate our support for an API to underpin the consent lifecycle in the CDR, and recommend Data61 work closely with the OIDF to further develop their Grant API proposal, so the industry can move forward with an open standards-based approach.

[sakimura]

As I previously introduced, my name is Nat Sakimura and I am one of the Chairs of the Financial-grade API Working Group (FAPI WG). Following on from our previous feedback within this Decision Proposal the FAPI WG have reviewed the response provided by the Data Standards Body (DSB) and provide a detailed response with our evaluation of the proposal.

Our response includes the following key areas of feedback:

Adoption of the FAPI 2.0 profile

Adoption of Pushed Authorisation Request (PAR)

Adoption of JWT Secured Authorization Request

Non adoption of Rich Authorisation Request (RAR)

Non Adoption of Grant Management Extension & API

Sharing Agreement API Introduction

In addition the FAPI Working Group propose a Stage approach to adoption. While intertwined with the long term roadmap of the CDR as a whole we acknowledge that the scope for this feedback is intended to be specific to the Concurrent Consent requirements. With this in mind the FAPI Working Group requests consideration of this content to be included in development of other related Decision Proposals, notably #108 and #106.

In addition the FAPI Working Group continues to make available it’s expertise to the Data Standards Body. In addition to the OpenID Foundation and the Working Group body itself the following additional members have expressed their willingness to engage with the DSB to provide further background on lessons learned:

Open ID Foundation members:

Joseph Heenan - Open ID Certification Suite Developer & CTO at FinTechLabs.io

Don Thibeau - Executive Director at Open ID Foundation

Members of the Open Banking Implementation Entity (OBIE) within the UK, specifically:

Imran Gulamhuseinwala - OBIE Trustee at OBIE

Ed Colley - Programme Director at OBIE

Chris Michael - Interim Head of Technology at OBIE

Ralph Bragg - Ecosystem Trust Framework Architect at OBIE

Authors of all of the referenced specifications including:

Dr. Torsten Lodderstedt - Author of OAuth 2.0 Threat Model (RFC6819), OAuth 2.0 Token Revocation (RFC7009), OAuth2 MA-TLS (RFC8705), FAPI Grant Management, FAPI Pushed Authorisation Request, FAPI JWT Secured Authorization Response (JAR)

Dr. Daniel Fett - Author of OAuth 2.0 Threat Model (RFC6819), FAPI 2.0 Baseline Profile, FAPI 2.0 Attacker Model

Nat Sakimura - Author of JWS (RFC7515), JWT (RFC7519), PKCE (RFC7636), JWK (RFC7638), OAuth2 MA-TLS (RFC8705), FAPI 1 Part 1, FAPI 1 Part 2, OpenID Connect Core

Ralph Bragg - Author of FAPI 1 Part, FAPI 1 Part 2, FAPI JWT Secured Authorization Response (JAR)

Executives of the Financial Data Exchange, a North American open data initiatives with members from all of North America’s largest financial institutions

FAPI WG Decision Proposal 99 Response.pdf

Reiterating on my first response, while some Australian requirements are unique, the problem is not. Let’s solve it together for the benefit of the customers in multiple jurisdictions. Australia has already demonstrated leadership towards adopting best security practice with it’s progression towards FAPI 2.0 and we welcome the continued opportunity to collaborate further.

[perlboy]

As a contributing member of the FAPI WG, a longtime contributor to the CDR and vendor to both Data Holders and Data Recipients, Biza.io endorses and supports the staged approach outlined within the FAPI WG response provided by @sakimura . Based on the currently understood timelines, we expect our products to be entirely compliant with FAPI 2.0 by launch and prefer international standards alignment over unnecessarily unique Australian approaches.

[CDR-API-Stream]

Thanks everyone for all your feedback and participation. The feedback period has now closed. The DSB will review the responses and will provide additional commentary here.

[CDR-API-Stream]

For noting: AGL provided a response to this decision proposal within the consultation window. Inline with the DSB's open consultation process it has been posted here for visibility.

AGL submission concurrent consent target state - 9 April.pdf

[CDR-API-Stream]

Please find the final decision document attached here: Decision 99 - Concurrent Consent.pdf

This decision has been incorporated into v1.3.0 of the standards.