[ARCHIVE] Expected behaviour for scopes presented by an ADR to a DH

Archived 22/02/2024. Please see CDS Guide on Authorisation Scopes.

23/08/2022: New Guidance from the Data Standards Body (DSB) and Australian Competition and Consumer Commission (ACCC) has been published here: Guidance for ADRs connecting to Data Holders using unsupported scopes

Question

Would an ADR’s SSA issued for July go-live contain future dated scopes that are not currently supported (e.g.: Scheduled payments and direct debits)?

Answer

1. Whilst an ADR may include scopes not currently designated for a DH, the DH would return a response with the "scope" claim populated with the scopes supported by the DH. This ensures that an ADR knows the subset of scopes that a given DH can accept

2. As described, the DH would allow the request but accept the client registration with the subset of scopes the DH supports per RFC7591. This would be acknowledged in the Dynamic Client Registration /register response payload.

3. Not applicable. However, an ADR would need to periodically check the scopes supported by the DH through the DH's /.well-known/openid-configuration endpoint. When additional scopes are supported by a DH it may be in the interest of the ADR to expand their use case to handle those extra capabilities. This is important for different scopes tied to different phasings of obligation dates as well as DHs being able to support competitive extensions represented under additional scopes.

Additional scopes presented during the consent flow
These questions also give rise to what is the expected behaviour during the authorisation flow?
If an ADR requests authorisation with a set of scopes beyond what the DH supports (say the DH supports bank:accounts.basic:read but the ADR requests consent for both bank:accounts.basic:read and bank:accounts.detail:read) then as per OIDC a Data Holder should ignore the extraneous scopes. This ensures there is alignment with the RFC but it also doesn't penalise ADRs as they are developing software products that span a number of DHs with different obligations.

Consumer Experience
That being said, there is an expectation that an ADR will tailor their use case to the data cluster support offered by a given Data Holder ahead of time. An ADR that does not negotiate their use case may create unnecessary consumer friction where successful consent establishment must be immediately revoked because the authorisation grant does not include the required scopes to fulfil the ADR use case. This negotiation is possible prior to the consent flow by calling the Data Holder's OIDC /.well-known/openid-configuration endpoint.

No scopes supported
If the ADR attempts to establish consent but the DH does not support any of the requested scopes , the DH must reject the authorisation request.

See

• Standards Maintenance Issue 243