...
The AISP connects to the ASPSP that services the user/customer’s account(s) and creates an account-access-consentconsents resource. This informs the ASPSP that one of its user/customers is granting access to account and transaction information to an AISP. The ASPSP responds with an identifier for the resource (the ConsentId - which is the intent identifier). This step is carried out by making a POST request to / account-access-consents endpoint.
The account-access-consent consents resource will include these fields below - which describe the data that the user/customer has consented with the AISP:
Permissions - a list of data clusters that have been consented for access.
Transaction Validity Period [D1] [D2] - the From/To date range which specifies a historical period for transactions and statements which may be accessed by the AISP.
...
The AISP requests the user/customer to authorise the consent. The ASPSP may carry this out by using a redirection flow or a decoupled flow.
In a redirection flow, the AISP redirects the user/customer to the ASPSP.
The redirect includes the ConsentId generated in the previous step.
This allows the ASPSP to correlate the account-access-consent that was setup.
The ASPSP authenticates the user/customer.
The ASPSP updates the state of the account-access-consent consents resource internally to indicate that the account access consent has been authorised.
Once the consent has been authorised, the user/customer is redirected back to the AISP.
In a decoupled flow, the ASPSP requests the user/customer to authorise consent on an authentication device that is separate from the consumption device on which the user/customer is interacting with the AISP.
The decoupled flow is initiated by the AISP calling a back-channel authorisation request.
The request contains a 'hint' that identifies the user/customer, paired with the consent to be authorised.
The ASPSP authenticates the user/customer and updates the state of the account-access-consent consents resource internally to indicate that the account access consent has been authorised.
Once the consent has been authorised, the ASPSP can make a callback to the AISP to provide an access token.
The principle we have agreed is that consent is managed between the user/customer and the AISP - so the account-access-consent details must not be changed (with the ASPSP) in this step. The user/customer will only be able to authorise or reject the account-access-consent details in its entirety.
During authorisation, the user/customer selects accounts that are authorised for the AISP request (in the ASPSP's banking interface).
...
The API endpoints for creating account-access-consent consents resources are not idempotent.
If a time-out error occurs - then we would expect an AISP to create a new account-access-consent consents resource - rather than try with the same resource.
...
2.3.1 Account Access Consent
The account-access-consent consents resource is referred to as an account-request resource in v1 and v2 of this specification. For clarity, it has been generalised to 'Consent' in the detail below
...
The AISP must create an account-access-consentconsents resource through a POST operation. This resource indicates the consent that the AISP claims it has been given by the user/customer to retrieve account and transaction information. At this stage, the consent is not yet authorised as the ASPSP has not yet verified this claim with the user/customer.
...
3.3.1 Consent Elements
The Account Access Consent Consents resource consists of the following fields, which together form the elements of the consent provided by the user/customer to the AISP:
...
3.3.2 Account Access Consent Status
The Account Access Consent Consents resource may have one of the following status codes after authorisation has taken place:
...
The AISP must cease to access the APIs at that point.
The AISP must call the PATCH operation on the account-access-consent consents resource (before confirming consent revocation with the user/customer) as soon as is practically possible, to indicate to the ASPSP that the user/customer has revoked consent
...
The ASPSPs must revoke the access token provided to the AISP.
The status of the account-access-consent must remain unchanged and the AISP must be allowed to request user/customer to re-authenticate the same account-access-consent consents resource.
Upon successful re-authentication by user/customer, an ASPSP may issue new authorisation code and subsequently new access token to the AISP.
...