Question
Are there any dependencies in regard to Authorisation Scope and Consents?
For example, on one account, could a customer authorise bank:accounts.basic:read and Collection Consent, and on another account the same customer authorise bank:payees:read and Use Consent?
Answer
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).
That said, with the same Authorised Data Recipient (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.
See:
Comments
3 comments
Could you please clarify where in the standards it is specified that a consent is made up by a set of scopes and a list of accounts these scopes apply to? None of the referenced links in the response mention that scopes apply to a specific set of accounts, which is commonly known as fine grained consent. In fact, Consent mentions that fine-grained consent may be incorporated in the future, which would seem to indicate that it is not required now.
Hi Debora,
Within the standards the scopes do not apply to specific accounts and the standards do not have any statements indicating that accounts are included in consents. The association of an account with a consent is not considered fine grained authorisation as these associations are not considered to be part of the consent itself.
The ADR is unable to ask for consent to access specific accounts as, to do so, the ADR would need to have a list of the available accounts first. The provision of this list would be data sharing itself requiring consent. Also the rules make provision for data sharing of specific accounts to be removed by a third party, such as the rules governing the Joint Account Management Service for instance. If the accounts were included in a consent then this would result in a third party being able to revoke or amend an authorised data sharing consent which would not be desirable.
As a result, accounts are considered to be attached to an authorised consent but not part of the consent itself. This is effectively analogous to approaches in other jurisdictions where the ability to share data for an account follows the permission to transact on the account but does go a little further in that it allows for a customer to determine exactly which available accounts should be associated with a consent.
This is not covered explicitly in the standards as it is mainly governed via the rules regarding account inclusion, especially the rules regarding the joint account management service. If this is confusing we would welcome a change request to clarify this position.
- James
Thanks James Bligh for your response. I'm still confused as to at what point of the authorisation stage are a list of accounts attached to a consent, for what purpose, and by whom. I understand an ADR cannot do it before the consent has been granted by the end user. So is it the DH? Or is it the ADR, after the initial consent (when it can actually obtain the list of accounts associated with a customer)? If the former, is that list of accounts communicated to the ADR? Or is it just information that the DH is meant to store but not share with ADRs?
I know this sounds like too many questions, but I've been reading the standards for quite a long time now (and implementing them from a DH point of view) and it was my impression that all a DH needed to present to an end user was a list of scopes for them to select
Please sign in to leave a comment.