Consent - Glossary - API Explorer

Consents provide a mechanism through which a resource owner (e.g. a customer) can grant a third party certain access to their resources.

The following are important considerations in Consent flows:

The privacy of the resource owner (the Customer or User) should be preserved.

This means that when a TPP first asks a User if they would like to provide their data, the user should not be authenticated. Thus the start of the Consent process authenticates the Client (TPP) but not the User.

Authentication of the user comes later.

<a href="http://localhost:5174/operationid/OBPv5.0.0-createConsentRequest">This endpoint initiates a consent in OBP</a>

Consent finalisation often involves SCA.

Since a consent gives its holder privileges on the API, we need to make sure it is not created lightly, therefore some second factor of authentication is employed.

<a href="http://localhost:5174/operationid/OBPv5.0.0-createConsentByConsentRequestIdSms">This endpoint finalises an OBP consent</a>

A User should be able to list and revoke their consents.

<a href="http://localhost:5174/operationid/OBPv5.1.0-getMyConsents">This endpoint lists consents for the authenticated user.</a>

<a href="http://localhost:5174/operationid/OBPv3.1.0-revokeConsent">This endpoint revokes a consent for the current user.</a>

This gives the user visibility over the consents they have granted to various apps for various purposes and confidence they can stop the TPP acting for a certain purpose.

The consent manager should be able to list and revoke consents.

<a href="http://localhost:5174/operationid/OBPv5.1.0-getConsentsAtBank">This is a management endpoint lists consents with various query parameters</a>

<a href="http://localhost:5174/operationid/OBPv5.1.0-revokeConsentAtBank">This is a management endpoint to revoke a consent</a>

The consent manager may want to list the consents by each Client or User and the ability to revoke individual consents (rather than disabling a client completely).

This requires that the resource server stores the CONSENT_ID and other information so that it can be disabled or queried.

However, the consent manager should not be able to see the CONSENT_ID since this would make it easier to actually use it.

A consent is bound to the application has created it.

The User gave consent to a certain application not any application.

The consent will have a limited life time.

The consent can become valid in the future and need not last forever.

The consent will be signed using JWT.

This increases the security of the claims contained in the consent.

What an OBP Consent carries

key	nature	check when the Consent is created
`views`	the User's own account access (owned)	the User has the view
`entitlements`	Roles at a Bank or the system (granted)	the User holds the stored Entitlement; virtual Entitlements do not count
`my_resources`	the User's own personal resources (owned), one typed list per kind, e.g. `personal_dynamic_entities`	the kind and instance exist; no Role, the User owns these rows

my_resources is accepted by the Create Consent endpoint from v6.0.0 (older create-consent bodies are frozen). Example: {"personal_dynamic_entities": [{"bank_id": "SYS", "entity_name": "FooBar", "actions": ["read", "write"]}]}. The bank_id of an entry is the space the entity lives in: SYS for a system-level entity, or the id of the Bank. An empty bank_id also means the system space. An entry names what the consent user may act on for the granting User; rows it writes belong to that User. Absent or empty means none, and everything: true does not include it. See here.

See here for an example flow. See here for more information about onboarding.