Archived 26/02/2024. Please see the Consumer Data Standards and Data Language Standards: Common.
Question
CX Standards Data Language Standard states: "If a scenario requires it, Data Holders and Data Recipients MUST merge and amend Basic and Detailed data cluster and permission language to show that Detailed
scopes include Basic data."
However CDS Authorization Scopes states: "Granting this authorisation only makes sense if the Bank Account Data
scope is also authorised."
In addition the wording on endpoints includes only the Basic versions rather than stating, for example, "To perform this operation, you must be authenticated and authorised with the following scopes: bank:accounts.basic:read
" rather than "To perform this operation, you must be authenticated and authorised with the following scopes: bank:accounts.basic:read
or bank:accounts.detail:read
".
If a Data Recipient includes only the detailed scope what should a Holder do? Is it expected the Holder will assume on the Data Recipients behalf, that the authorization request is for both basic and detail, effectively amending the authorization request?
Alternatively, if the Data Recipient does not include the basic scope should the request be rejected or should it proceed without the Basic component?
In both the implied and explicitly included cases, it is assumed that the presence of both scopes would result in the alternate CX rendering. Is this correct?
Answer
This question has two answers, one in reference to Technical language and one in reference to CX language.
Technical Answer:
At the core of this issue is a variation in how the CX language standards and the CDS standards address this issue.
From a technical perspective, each scope 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. Also, as you point out, each end point requires authorisation of one, and only one, scope.
The CDS Authorization Scopes note, "Granting this authorisation only makes sense if the Bank Account Data scope is also authorised", does not state, or imply, that an authorisation request with only the detailed scope and without the basic scope is invalid. The purpose of this note is to highlight that there is information obtained from the basic scope end points that may be needed to access the detailed scope end points. For example, you need the account ID from the account list end points before you can supply it to the detailed end point.
There are, however, situations where it may be appropriate for an ADR to make a request without authorising both scopes. Concurrent consent is possible and account IDs are held consistent across multiple concurrent consents. For instance, it is possible to request the basic scope in one consent and the detailed scope in another consent.
In summary, from a technical perspective, each scope is separate and distinct and one scope does not imply any other scope. If an ADR requires a set of scopes that aren't useful that is their choice.
CX Answer:
The CX response to this query reflects the one in issue 224 but has been adjusted slightly for clarity. The data language standards are structured in a way that allows ADRs and DHs to apply the standards to a range of scenarios, including where an ADR requests scopes that aren't ostensibly useful.
The intention of the merged language is to make clear to the consumer that authorising detailed scopes may provide access to basic data - not that the DH should include basic scopes on the ADR's behalf.
The expectation in the technical standards is for the ADR to request basic scopes whenever detailed scopes are requested, as outlined below:
For bank:accounts:detail:read
, the standards state it 'is effectively additional authorisation to the Basic Bank Account Data scope. Granting this authorisation only makes sense if the Bank Account Data scope is also authorised. Includes basic account information plus account identifiers and product information.'
For common:customer:detail:read
, the standards state it 'Includes the data available with the Basic Customer Data scope plus contact details.'
While the above ADR behaviour is expected it isn't mandatory, so the CX language is designed to accommodate a variety of scenarios.
The expected data language to be used by the DH is outlined below:
- If the ADR ONLY asks for the basic scope (for either customer or accounts), the expectation is for the DH to only display the data language for the basic cluster.
- If the ADR ONLY asks 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.
Comments
2 comments
Based on this statement:
There does not appear to be any scenario where the detailed data cluster is ever used and consequently the merged language is, in essence, the detailed language making the business logic far simpler than originally implied.
Thanks for the follow-up comment Stuart. The circumstances for the unmerged language is primarily for circumstances where the customer is presented a choice as to whether to include one or both of the scopes. This would be the case for the ADR when presenting the scopes where they require basic data for the purpose to be delivered but optionallyrequest detailed for added value functionality.
Also, as the regime evolves and consent amendment potentially expands the unmerged language would likely be useful in a flow where an existing consent is amended.
The standards deliberately seek not to be too specific on when to use the merged and unmerged language and leave it to participant discretion in case there is a specific case that we haven't anticipated.
Please sign in to leave a comment.