Decision Proposal 77 - Consent

[CDR-InfoSec-Stream]

This thread has been created to publish the decision relating to how consent will be captured for the initial CDR implementation.

The decision paper is pending approval by the Chair but is intended to be published on the 15th July.

[Technical-DSB]

Please find attached the approved decision regarding the incorporation of Consent into the standards.
Decision 77 - Consent.pdf

Note that no decision regarding a Centralised Consent Dashboard has been taken. This will be the subject of further consultation and customer experience research.

[perlboy]

Through the above decision the Consumer Data Standards Australia has adopted a position which does not align with the UK Open Banking Standards as they stand now nor where they appear to be headed. Additionally the decision adds an optional claim (which, outside of one-off authorisation is in-fact mandatory) which is not documented within OpenID Connect Core 1.0 nor part of the JSON Web Token Claims Registry.

That is to say "optional claims" does not imply the ability to inject new claims without first being registered and approved for membership within the JWT Claims Registry. Further, for interim claims (as per those used by Open Banking UK) pending a formal registration new attributes should be strongly scoped (ie. prefix with a URI).

Based on OpenID FAPI working group direction (ie. Lodged Intent) registration into the JWT Claims Registry seems likely to be denied. As per the Recommendations incorporated in the Executive Summary of the Review into Open Banking issued in December 2017 by the (then) treasurer Scott Morrison:

Recommendation 5.2 – starting point for the data transfer Standards

The starting point for the Standards for the data transfer mechanism should be the UK Open Banking technical specification. The specification should not be adopted without appropriate consideration, but the onus should be on those who wish to make changes.

While alternatives to the decision have been outlined the decision document does not outline what the appropriate consideration was that led to the introduction of a mandatory non-standard claim in a location which is intended for registered optional claims. Further there does not appear to be any documented impact assessment for holders, recipients and their vendor partners with respect to the implementation of this decision. Indeed multiple respondents in the May Draft Feedback Cycle have recommended participation within international working groups and recommended the adoption of a mandatory Consent API (by my count, 3 of 4 of the Big 4).

As per "the onus should be on those who wish to make changes", please provide information and justification as to why Consumer Data Standards Australia has elected to not collaborate with the OpenID Connect Working Group and Open Banking UK to align to the existing International Standards and the emerging FAPI Lodging Intent proposal.

[perlboy]

Further on the above Biza.io notes that the CDR Rules outline published by ACCC state the following in section 7.2.9:

The authorisation Standards must:
a. be subject to consumer testing and may contain service level requirements
b. provide for multi-factor authentication requirements consistent with the
requirement for strong customer authentication under the revised Payment
Services Directive (EU) (PSD2) and the European regulatory technical
standard for strong consumer authentication under PSD2 regulatory technical
standards (RTS)

Specifically on the RTS the following is a quote from this guideline:

From amendment 15:

To ensure the interoperability of different technological communication solutions, the interface should use standards of communication which are developed by international or European standardisation organisations.

From Section 2 part 4:

Account servicing payment service providers shall ensure that their interface(s) follows standards of communication which are issued by international or European standardisation organisations.

[bmangalaganesh]

I need a better understanding of this space - "Fine-grained Consent".

The CDS website states - Other patterns for the establishment of consent may be considered in the future, including the incorporation of fine-grained consent for specific use cases.

The Cx Guideline shows the user choosing multiple accounts as part of the flow and this appears to contradict the decision stating fine-grained consent is not supported.
<From the decision 77 document >

The selection of the list of accounts to be shared is an example of this form of fine-grained consent.

Would love some clarity in this space.

[perlboy]

The decision outlined here does not appear to cover the comments regarding a single consent per holder/recipient pair nor the overriding of existing consents with new permissions.

This was specified in a recent response by @CDR-API-Stream: #79 (comment)