Introduction
FAPI migration
The migration to FAPI 1.0 uses a phased approach. The migration of the entire CDR ecosystem to fully support FAPI 2.0 is expected to complete in early 2023. For an ADR with a hard dependency on expecting scopes, failure to return the scopes breaks the ADR (Accredited Data Recipient) software product. Given some DHs (Data Holders) are not currently compliant, it is unlikely any ADR has a hard dependency.
Limited scope profile
An authorisation request by an ADR with only openid or openid/ profile in scope should be accepted by a Data Holder. While the request may not receive any shared data in response, the request could act as a test to check the authorisation response.
Consent category dependency
Each consent has a set of scopes. A set of accounts is attached to the consent. Accounts are attached to a consent but not included in the consent. Data sharing for all attached accounts is according to the authorised scopes in the consent. No account specific scopes are created in the CDR (Consumer Data Right). However,> with the same ADR, a consumer can create many different consents, each with different sets of scopes and different sets of associated accounts, if the ADR supports this scenario.
Basic and Detailed Scopes
From a technical perspective, each scope whether basic or detailed is a separate scope and is treated as a separate scope. In the technical standards, there is no merging of scopes and scopes cannot be inferred. Every end point requires authorisation of one, and only one, scope.
Following the CX standards, the expected data language to be used by the DH is outlined below:
- If the ADR asks ONLY for the basic scope (for either customer or accounts), the expectation is for the DH to display only the data language for the basic cluster.
- If the ADR asks ONLY for the detailed scope (for either customer or accounts), the expectation is for the DH to display the merged language. This is because detailed scopes include basic scope data.
- If the ADR asks for BOTH basic and detailed scopes (for either customer or accounts), the expectation is for the DH to display the merged language.
Payee Scope Request
An ADR can request only payees' payload/information from a DH without requesting any other scope.
Mandatory Scopes Request
The only mandatory scope is the openid scope that is required by the OpenID Connect Core normative standard, all other scopes are optional.
Consent for Data Scope
If an ADR gets consent for data scope A & B then a valid request is for scope with A, B or A+B.
It should be noted that in general all API end points and payloads are specific to a single scope. This has been a goal of the Data Standards Body to simplify issues of this nature.
Currently, with the exception of the inclusion of payeeId in the scheduled payments end point response, there are no scenarios where a single payload requires multiple scopes.
Expected behaviour for scopes presented by an ADR to a DH
If an ADR includes scopes not currently designated for a DH, the DH should return a response with the "scope" claim populated with the scopes supported by the DH. This ensures that the ADR knows the subset of scopes that a given DH can accept.
If an ADR requests authorisation with a set of scopes beyond what the DH supports, then as per OIDC a Data Holder should ignore the extraneous scopes. However, it is expected that 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.
An ADR should 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.
Comments
0 comments
Please sign in to leave a comment.