Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes

[CDR-API-Stream]

Description

The introduction of the energy sector will introduce the following new authorisation scopes to the CDS:

New Authorisation Scopes for Energy
energy:electricity.servicepoints.basic:read
energy:electricity.servicepoints.detail:read
energy:electricity.usage:read
energy:electricity.der:read
energy:accounts.basic:read
energy:accounts.detail:read
energy:accounts.paymentschedule:read
energy:accounts.concessions:read
energy:billing:read

Banking data holders who do not participate in the energy sector are not going to support energy APIs and the associated authorisation scopes.

Clarification is required on how data holders should behave when receiving registration create and update requests where the SSA scope field is populated with unsupported scopes.

Area Affected

Security Profile > Client Registration

Change Proposed

This is not the first time where unsupported scopes have been populated in SSAs. Banking sector phasing resulted in this scenario occurring.

Feedback on this issue needs to be reviewed and considerations made as to whether the standards need to articulate this behaviour

[CDR-API-Stream]

For reference, guidance on this issue has previously been provided: https://cdr-support.zendesk.com/hc/en-us/articles/900001781826-Expected-behaviour-for-scopes-presented-by-an-ADR-to-a-DH

[CDR-API-Stream]

It has been an expectation that Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations, as reflected in the following guidance: https://cdr-support.zendesk.com/hc/en-us/articles/900001781826-Expected-behaviour-for-scopes-presented-by-an-ADR-to-a-DH

However, this hasn't been explicitly called in the standards and there is an opportunity for the standards to clarify this scenario.

The DSB proposes that the standards are updated to specify that:

Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations.

A future dated obligation would align this change with the Energy release timeframe of 15th November 2022.

[ACCC-CDR]

ACCC strongly supports the proposed change outlined above and requests an earlier obligation date to support the introduction of Energy. ACCC proposes 15th September 2022 as the future dated obligation, to ensure Data Holders are responding correctly to data requests prior to the implementation of the Energy Sector.

[CDR-API-Stream]

After incorporating feedback from the community through maintenance iteration 10, the proposal is being updated to move this requirement from a SHOULD to a MUST.

The DSB now proposes that the standards are updated to specify that:

Data Holder Brands MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations.

Regarding changing the FDO to 15th September 2022, further discussion is required to consider having an FDO less the 6 months out. Changes to the FDO will not be considered as part of maintenance iteration 10 however, will be considered for maintenance iteration 11.

The DSB invites the community to comment on this change

[CDR-API-Stream]

Issue #507 has been raised to investigate the opportunity for modifying the FDO date for this piece of work

[CDR-API-Stream]

A dependency date was set as 15 November 2022 to align with the Energy release timeframe and considerations to change this date will be discussed further through Issue #507 in Maintenance Iteration 11.

This change was incorporated into release v1.17.0.

Please refer to Decision 237 for further details.

[SlatsFR]

ForgeRock is seeking clarification. This article https://cdr-support.zendesk.com/hc/en-us/articles/900001781826-Expected-behaviour-for-scopes-presented-by-an-ADR-to-a-DH states that:

"As described, the DH would allow the request but accept the client registration with the subset of scopes the DH supports per RFC7591"

However, this RFC does not state that subsets of scopes should be supported during Dynamic Client Registration. It states:

"The semantics of values in this list are service specific. If omitted, an authorization server MAY register a client with a default set of scopes."

This comment appears to indicate that either a precise set of scopes be requested during DCR, or none at all.

RFC7591 does point to RFC6749 [https://www.rfc-editor.org/rfc/rfc6749] which allows subsets, but as RFC6749 pertains to authorization, not registration, this is seen by ForgeRock as irrelevant.

Question
Has this change proposal been backed by the OAuth2.0 standard? (and could you please point me to the document, or perhaps point out any misunderstanding of the above document/s?) Or has CDR requested a change to the standard to allow vendors to enable our customers to support the approach?

[CDR-API-Stream]

Hi @SlatsFR, the reference in regards to RFC7591 is towards general dynamic client registration requirements.

The reason for DHs ignoring unsupported scopes is due the the way the CDR Register operates. It issues the SSA signed using the Register CA cert incorporating all scopes an ADR is accredited for. The way the CDR Rules are expressed it means that once a data recipient is accredited, they are accredited for all sectors and hence all scopes across those sectors: right now that is banking and energy. In future that will include telecommunications etc.
​
To ensure that an ADR can successfully manage their client registration with a DH when they present all scopes (noting that the ADR cannot control which scopes the CDR Register generates for it), the DH needs to facilitate the client registration updates without rejecting the request.

Hope that helps.
​