Decision Proposal 066 - Authorisation End Points

[JamesMBligh]

This issue has been opened to capture, document and obtain feedback on a subset of the Information Security profile for the CDR regime with a view to finalisation and endorsement by the Chair of the Consumer Data Standards body.

This issue is specifically describes the endpoints expected to be supported under the regime (in addition to those defined by the API working group - including administration endpoints)

The proposal is now provided below. Feedback will be open until the 17th May.
Decision Proposal 066 - Authorisation End Points.pdf

[JamesMBligh]

The decision proposal has now been published.

-JB-

[spikejump]

Hi James,

There might be some typos in the decision proposal.

1. Token Endpoint is defined in 3.3.3 of OIDC and not 5.3
2. UserInfo Endpoint is defined in 5.3 of OIDC and not 3.3.3.

The two seems to be wrong way around.

In addition, regarding Revocation, there's a statement of "Data Holder’s MAY notify the Data Recipient of the invalidation of an Access Token or Refresh Token but this is not required." There's no corresponding statement of whether Data Recipients are required to notify Data Holders.

In any case, is it not a better approach to make it mandatory that both Recipients and Holders MUST notify each other when a revocation has occurred? The two sides should not be out-of-sync in terms of the their understanding of consent permission. If they were that can lead to a lot of confusion for the Customer, Recipient, Holder and possible security holes.

Thanks.

[JamesMBligh]

Hi @spikejump, thanks for highlighting the typos. I have fixed this and republished the document in the main comment.

Regarding mandatory notification of revocation, this is already mandated by the ACCC Rules in section 4.11 (2) and 4.24 (2). That said, it doesn't hurt to be clear so I have added clauses that replicate the existing requirement in the rules to this proposal.

The intent of the proposal is that, as Customer revocation is achieved using the Sharing ID and there is also a clause requiring that Access and Refresh tokens be invalidated by Recipients and Holders when a revocation occurs, then a Customer revocation will result in all tokens being cleaned up by both parties without the need for a call to the revocation endpoint for each token.

-JB-

[NationalAustraliaBank]

As previously articulated:

1. “Dynamic registration MUST not be supported” (quoted from DP#66)

NAB is currently concerned and strongly opposed to the proposed registration solution due to the ramifications it could create. To reduce the level of complexity and increase support for standard protocols, NAB is supportive of the implementation of Dynamic Registration from day 1 as per feedback provided to the InfoSec issue #63.

2. “A Consent API is no longer included in the Information Security profile” (quoted from DP#66)

As previously mentioned on DP#64, and DP#62, NAB is strongly opposed with the implementation of a solution that consolidates identity management and consent / permission management. In addition to the points previously articulated, there is a risk that the proposed solution exposes unknown security vulnerabilities. NAB supports best practices as seen in the UK implementation, which separates these security and business concerns, and expects that due-diligence Security Assurance activities on the proposed solution are performed.

[JamesMBligh]

In response to @NationalAustraliaBank

• the choice to remove dynamic registration is in response to an expectation that the ACCC Register will be the point of static registration. If that assumption holds true then dynamic registration will be redundant. A response (Dynamic registration of accredited data recipients infosec#63 (comment)) was provided to this effect in your response to the feedback you previously provided. Is there additional information that would be worth considering on this topic or is this a reiteration of the previous feedback?

• The removal of the consent API has been responded to a number of times. Specifically a more detailed response has been provided here Decision Proposal 062 - Authorisation Flows #62 (comment). More explanation of how the current position, which essentially consists of minor amendments to standard OIDC, would expose unknown security vulnerabilities. It is also unclear how this choice consolidates identity and consent. The standards have been carefully constructed to leave identity entirely in the competitive space.

-JB-

[anzbankau]

Dynamic Client Registration – ANZ supports view shared across the board on adoption of standards and that strong consideration be given to support dynamic client registration to avoid complexity in building, supporting and certifying bespoke implementation. This could also means delays on both Data Recipient and Holder to deliver as any standard tools and product offering from vendors won’t offer support to custom approach.

We appreciate further clarity in InfoSec standards on how authentication and trust will be established between Data Holder and Recipient in absence of central trust. In specific distribution of client IDs and credentials.

ANZ is supportive of consent API removed from standards.

[mperryau]

Ping Identity is concerned with this proposal in its current form. We believe it will cause issues for us and other solution providers, and therefore to CDR Data Holders and system implementation partners.

In the section Introspection Endpoint, this proposal states:

Introspection of Sharing IDs MUST be supported. In this case the token_type_hint parameter MUST be set by the client to sharing_id to indicate that the token parameter contains a Sharing ID.

By requiring this to be performed as part of the introspection end point, Data61 is essentially defining a new standard / profile on top of OAuth2 to define this token type, and this new profile is currently not supported by any vendor, increasing the cost of implementation for all participants through additional customisation.

In addition, the definition of a new standard in this instance, as it extends OAuth2, would require more detailed definition and analysis as its presentation is currently is more aligned to a claim than a token. We would also recommend that this approach be reviewed by a security specialist.

The Sharing ID in this proposal is not a token — it's an identifier, and it shouldn’t be treated or modelled as a token. The OIDC token which this seems to be modelled on is a specific case to assert federated identity. Modelling sharing IDs in the same manner (while it may be able to be made to work) creates additional customisation for Data Holders when compared to adoption of an approach that is already supported by multiple vendors.

We strongly recommend adopting the current draft Open ID Foundation’s FAPI consent resource. This is widely adopted by vendors and aligns with global direction. It is also feasible that when this standard is ratified in the near future it would be introduced into the CDR standards, deprecating the need for the Sharing ID.

We request that Data 61 rethink this design as we believe it will not be beneficial for the CDR in the short or long term, and in fact, could introduce security issues of its own.

[WestpacOpenBanking]

Westpac shares NAB’s concerns and opposition to the proposed solution for client registration and the abandonment of a consent API. We re-iterate our comments in relation to Decision Proposal 064, Decision Proposal 067 and Infosec Issue 63.

Transport Layer Security and Certificate Validation

As mentioned by Ralph Bragg in response to issue 33, MTLS, as defined in the normative reference [MTLS] is not a transport layer security protocol. Suggest that all references to MTLS, with respect to transport layer security are updated to TLS-MA and a link to the normative reference is added.

The exact method(s) of client credential validation and bearer token validation to be supported should be included in the document, or a reference should be made to a later decision that will outline this.

Similar detail should be provided for certificate validation rules. When is the chain of trust of the certificate required to be validated? When is the revocation status required to be validated? When is the DN required to be validated and against which field (Data Recipient name, client_id or other)?

Introspection Endpoint

Further detailed security analysis is required to understand the impact of presenting a non-secret (sharing ID) to an endpoint design to be used with secrets (access token, refresh token). Inconsistent treatment of sharingID as both a claim and a token is likely to have negative security implications, some of which may only be discovered after implementation. Westpac recommends an independent party is engaged to analyse the security of this proposal and give a recommendation. Further, it requires the customisation of OIDC-certified security infrastructure for handling access tokens and refresh tokens, thereby introducing potential errors and security vulnerabilities to the treatment of refresh tokens (and access tokens as well if introspection of access tokens were enabled).

As noted in our response to decision proposal #64, Westpac’s strong preference is to treat consent authorisation as a separate resource as per the draft FAPI standard for this.
However, if the current paradigm is to remain, our recommendation would be to include the expiry of the consent authorisation in the response to introspection of the refresh token.

Token Revocation Endpoint

Data Holder

Further detailed security analysis is required to understand the impact of presenting a non-secret (sharing ID) to an endpoint design to be used with secrets (access token, refresh token). Westpac recommends an independent party is engaged to analyse the security of this proposal and give a recommendation.

As noted in our response to decision proposal #64, Westpac’s strong preference is to treat consent authorisation as a separate resource as per the draft FAPI standard for this. However, if the current paradigm is to remain, our recommendation would be to use refresh token revocation as a representation of sharing revocation.

Data Recipient

We note that RFC7009 only describes how an authorisation provides a mechanism for a clients to revoke tokens issued by it. As such, RFC7009 does not apply to data recipients. We would appreciate either a normative reference to an applicable standard, or in the case that one does not exist, an explicit design that is vetted from a security perspective by an independent party qualified to do so.
This design should address the fact that currently, no notifying mechanism credential exists to allow the Data Holder to authenticate to Data Recipient. Additionally, the details on the transport layer connectivity for this should be outlined. Noting that this is an additional requirement for Data Recipients, Data Holders and the directory to establish this reversed trust flow. In line with our response to Decision Proposal 064, our recommendation is to model this as a resource on Data Recipient end because dealing with resources, rather than customising security infrastructure, will simplify matters for most (if not all) Data Recipients.

[JamesMBligh]

Thanks for all of the feedback. By request this issue will be kept open for further consultation until mid week.

[JamesMBligh]

In response to @mperryau and @WestpacOpenBanking, the feedback that the Sharing ID is not a token but is being treated as one is understood. In response to this the feedback below is from @WestpacOpenBanking is noted:

However, if the current paradigm is to remain, our recommendation would be to include the expiry of the consent authorisation in the response to introspection of the refresh token.

Clarification of any misunderstandings of this would be most welcome but, the understanding of this recommendation is that, the refresh token should act as the mechanism for introspection and revocation and that the sharing expiration should be treated as a claim associated with the refresh token. This would also mean that the Sharing ID would be unnecessary and could be removed from the proposal alleviating the concerns regarding the additional risks this ID could be introducing.

Adopting this suggestion would remove the Sharing ID from the proposal entirely and leave the refresh_token_expires_in claim and the sharing_expires_in claim. It would also mean that introspecting the refresh token would return the sharing_expires_in claim, revoking the refresh token would have the effect of revoking the sharing arrangement as a whole and reauthorisation would be initiated using the refresh token also.

The attraction of this variation to the current proposal would be to remove the ambiguity of what the Sharing ID is, would result in less variation to standard OIDC but it would still allow refresh token cycling and expiration of the sharing arrangement. All of these are desirable outcomes.

Has this suggestion been understood correctly?

[SlatsFR]

Hi James,

ForgeRock has concerns with the proposal to remove dynamic client registration in favour of a synchronisation process. The concerns are centred around the following:

• Dynamic Registration is a well understood component of the OIDC standard, implemented successfully for Open Banking globally. Moving away from Dynamic Registration breaks with patterns we know work.**
• Data layer synchronisation across firewall zones is troublesome and may cause integration issues, particularly as CDR expands beyond the big 4
• Standardising a data synchronisation process may be difficult given most organisations have their own implementations of directories, databases, etc.**
• Removal of Dynamic Registration introduces a hard dependency on the ACCC directory, it's sync process and cache, for client registration. This may introduce unforeseen issues in cases of outages, additional internal bank directories for autonomous registration / whitelisting / blacklisting of clients.

** A component of ForgeRock's concern stems from a lack of insight into the alternative solution. ie. We have not been able to find details on it.

Matt.

[WestpacOpenBanking]

In response to the @JamesMBligh‘s request for clarification:

We confirm that this is the correct interpretation of our response.

However note that, while removing the Sharing ID will address some immediate issues in the draft standards as they stand, Westpac’s strong recommendation is to use a consent object to manage consent information for the reasons outlined in our response to Decision Proposal 64.

Additionally, given the number of deviations from international standards in the draft Australian standards in totality, we recommend an independent security review is performed on the standards in their entirety when they are available.

[commbankoss]

Commonwealth Bank are supportive of NAB's position regarding implementation of dynamic registration and a consent API. We are concerned that Data61 and the ACCC are introducing bespoke solution flows and behaviours, and in doing so are not considering the substantial risk of new security vulnerabilities being introduced by deviating from industry standards. Implementing bespoke solutions means that it is more challenging for CDR participants to iterate to new security standards designed by the wider industry.

Deviation from Standards

Commonwealth Bank is concerned that the emerging CDR Standard deviates from existing common technical Standards leveraged internationally. Adopting altered OIDC scopes is fundamentally adoption of a new Standard.

The Standards currently imply that Introspection endpoint and revocation endpoint can be used to retrieve/revoke the sharing object. This is a deviation from OIDC standard for introspection and revocation endpoints. Introspection endpoint and the revocation should only be used to receive details or revoke OIDC tokens

CBA believes that 'sharing' related meta-information (e.g. sharing id, sharing duration) through an OIDC request and response is not a scalable solution. We recommend a separate Consent API resource for this purpose.

We are supportive of @mperryau regarding the adoption of an emerging Standard such as the draft Open ID Foundation's FAPI consent resource

The Registry
Commonwealth Bank recommends that the decision on the nature of registration in the Standards is decided only once further details of the Registry have been outlined by the ACCC.

The proposal states “Dynamic registration MUST not be supported”. We require assurances that the Registry will provide a highly available Certificate Revocation List (CRL) for data holders to query and that the Standards will define the mechanism for its use, so that the full capabilities of the Registry and CRL can be assessed. We recommend that the Standards clarify the distinction between Registration and Accreditation. We also seek further clarity regarding the rationale for moving away from implementing a Registry and registration process that is based on existing Standards and successfully implemented in the UK. Commonwealth Bank do not believe that there is material benefit from this possible implementation and remain concerned that bespoke solutions may not fully account for possible security vulnerabilities.

Consent API
We seek further clarity regarding the concerns behind adopting a consent API, specifically the concern that a consent API may present additional cost to participants. Data holders and recipients will need to design bespoke implementations which will need to be replaced as the regime is scaled to include other participants

[JamesMBligh]

Thanks for the feedback. This is all very useful and will be reviewed and incorporated. I'll be closing down feedback on this thread. Any additional feedback or points of clarification can be posted on the current open thread for feedback (#67)

The recommendation for an independent review of the profile has been noted and will be taken into consideration. The DSB has already done a review of this type after the December draft and the value of such a review is understood.

[JamesMBligh]

Please find attached the final decision covering this issue
Decision 061-066,068 - Information Security Profile.pdf