Question: What do I do if a TPP requests more or less scopes during Authorisation, DCR or Client Update?

[samlarsen1]

If we receive a PUT /register update for a TPP Client with a different (smaller) sub-set of allowed scopes, are we expected to delete all consents that have been previously issued which may include scopes that are no longer allowed? Or do we simply delete all consents? Or is this something we should evaluate in real-time for each resource API request?

e.g. Initial Scopes: openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft

New Scopes: openid accounts consents

[RalphBragg]

The requirement in this space was articulated in https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID1.md

shall ensure Access Tokens are issued with sufficient scope necessary for access to data specified in the Permissions element of a linked Consent Resource object;

Consumers will consent to a specific set of permissions (not scopes) with a TPP. A TPP, based on their regulatory roll is allowed to ask for these permissions at all times. i.e it is a DADOS. The obligation is placed onto the OpenID Provider to ensure that an Access Token is always issued that grants access to the consented permissions.

It has been raised previously that the inclusion of numerous scopes for the same regulatory given role is confusing and adds potential complexity, poorer user experience for no customer or security benefit. The security working group felt it was was too late to address as part of this first release however, in order to mitigate the impact of this issue, the requirements as specified in the security profile put the obligation on the banks to 'always ensure that an access token can be granted that will provide access to the resources permitted by the customer'.

For information, this same principle is echoed by the FAPI WG when it comes to Grant Management and Rich Authorisation Request (which is similar in a lot of respects to the 'Consent API'). If there is sufficient 'scope' in a RAR request to convey meaning and authorisation then an RS should honour the AT. It should not require a TPP to specify a 'fine-grained authorization_details in a 'RAR Payload' + 'A scope string' if the RAR authorization_details is sufficient to describe the request.

This direction from the OIDF FAPI WG has been applied here: The TPP has agreed and presented to the customers what PERMISSIONS it wishes to be granted. The TPP has defined what PERMISSIONS it wants in the Consent API of the Bank. The TPP requests the Bank to confirm with the customer that it wishes to have PERMISSION to access the requested resources.

ergo any access token issued should be sufficient for the TPP to gain access to those resources.

On a personal note; i'd prefer to see these myriad of scopes dropped in subsequent releases as, for our bank implementations are following the following logic on an Authorization request.

1. Adding additional scopes if required based on the permissions to scope mapping table communicated by the Functional API team.
2. Removing scopes if there are no permissions requested by the scope was requested.

RFC6749 "The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. " gives the ability for the Authorization Server to apply what it needs to in order for the 'Resource Owners instructions' to be carried out.

[alexasensio]

@RalphBragg I still think this question is unclear, at least for me.

Two scenarios to try to clarify the question:

Scenario A:

1. A TPP with role=DADOS + PAGTO registers a client with scopes: openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources payments
2. Customers create and authorize consents using appropriate permissions within those scopes
3. Tokens are issued and data is shared / payments are made
4. The TPP updates his client using PUT /register and asking only for a subset of those scopes: openid accounts consents resources
5. Consents had already been created with permissions that now do no longer fit within the TPP client's scopes
6. Does the ASPSP: a) revoke all consents for a client reducing its scopes, b) analyse all those consents on a case by case and only revokes those that contain permissions for a scope no longer supported by the TPP client, c) do not revoke any consents, but when a new token/refresh is requested that token is only issued/refreshed if the requested token scopes fit both the consent permissions AND the new TPP client scopes (note that scope is a optional parameter, as far as I understand it, and if it is not included, the previous scopes will be assumed to be requested, and therefore the token will not be issued due to the no longer supported scopes. Alternately, the Authorization server could decide to completely ignore the scope request parameter and assign to the token the new scopes, as per your last comment from the RFC6749). However this goes against the security profile specification that you mentioned: "shall ensure Access Tokens are issued with sufficient scope necessary for access to data specified in the Permissions element of a linked Consent Resource object;"; since the scopes overwrite the permissions granted by a customer. d) do not revoke any consents and keep issuing access tokens with the same scopes that fit the permissions of the consent. Only at the resources API request, analysis is done to respond with a 401 or a 403. In my opinion this is a waste of time and effort for both TPPs and ASPSPs as many calls will fail. e) something else?

Scenario B:

• Similar to the one above, but instead of the TPP updating its client using the PUT /register, the TPP fully looses one of its ROLES in the Directory:
• Does the ASPSP deletes the TPP client fully? or do similarly to the scenario above, option 6 a/b/c/d/e applies?

[RalphBragg]

Hi - so i would be applying the same logic that applies to 'rich authorisation requests' which is essentially what the Consent Object is.

"Since the scopes overwrite the permissions granted by a customer". Is incorrect using a referenced Consent. The Customer has consented to certain access, the TPP is allowed access to those resources by its regulatory permission ergo access should be granted. In the same way that rich authorisation requests authoriation_details are sufficient to grant access to this resource the scope should be ignored.

I have raised this many times with the security working group which is why the security requirements are explicit. The AS will ensure that access tokens are issued that have sufficient scope to provide access to the resources authorized by the customers. The customers authorise permission, transaction date ranges and associate accounts in the Consent Resource. Scopes are completely superflous. This interpretation applies also to RAR which is why it has been applied to lodging intent based resources. As defined by RFC7591 scope String containing a space-separated list of scope values (as described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client can use when requesting access tokens. 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.

The authorization server MAY reject or replace any of the client's requested metadata values submitted during the registration and substitute them with suitable values.

In order to address this for our Banking Customers, we are exercising this clause of RFC7591, they will always have access to the full set of scopes for their regulatory roles. This negates this problem and is one that i have recommended be adopted formally, or just remove all of these superflous scopes. Whenever a customer registers or updates their metadata the scope will be calculated based on their regulatory rules.

Scenario B. This is a revocation; if a TPP loses one of the regulatory roles that are defined in the directory the application in its entirety will be revoked. Notifications will be sent via webhook and the keys will be moved to an inactive state. This is the same approach in the UK.