Life-cycle of the consent
The diagram below depicts the live- cycle of consent in PSDHub.
Following statuses are supported:
Requested - authorize call has been received
Reused - authorize call has been received with existing consent id to be renewed
Registered- SCA link has been retrieved/ generated and provided back to consumer app (TPP app)
Authorized- oAuth code has been received after SCA
Confirmed - oAuth code has been exchanged for access and refresh token (optional since not ASPSP are supporting refresh tokens)
Deleted by PSU- consent has been deleted (deactivated) on TPP side (using PSDHub delete methods)
Invalid- consent has been identified as
expired in interaction with ASPSP (e.g. refresh token has been rejected as expired)
revoked on ASPSP side(e.g. refresh token has been rejected as revoked by PSU on ASPSP side)
deactivated by PSD2Hub due to a new SCA and new consent being received from ASPSP (for AIS APIs where only-one-IBAN is allowed for consent, it is invalidated only if new consent is issued for the same IBAN)
The key points marked on the scheme bellow which require particular attention:
Should delete of the consent also delete/deactivate the bank account?
ASPSP functionality allowing the consent invalidation should be discussed
In the current model when the IBAN is not required for SCA new consent will invalidate the previous one. In the flow with the IBAN, new consent will invalidate the old one when it is given for the same IBAN.
Transitions
|
| Current status | ||||
|
| Requested | Registered | Authorized | Confirmed | Invalid |
previousStatus | Requested |
| B |
|
|
|
Registered |
|
| D | E | G | |
Authorized |
|
|
| F | H | |
Confirmed |
|
|
|
| I | |
Reused |
| C |
|
|
| |
null | A |
|
|
|
|
A - SCA process has been started an is in progress (link not yet being sent back to the user). It can be removed after 10 minutes from status changed.
B - SCA process has been started and link has been sent back to the user. in most of the cases this is abandoned. It can be removed after 10 minutes from status changed since SCA link it time limit valid)
C - consent has been reused
D - SCA completed and oAuth has been received but not exchanged for AT/RT. It can be removed after 10 minutes from status changed since oAuth code is time limited valid.
E - All fine.
F - All fine.
G - Consent invalidated. Inmost of the cases due to expiration or problem after SCA.
H - as above
I - as above
New consent being issued.
We should consider all the four possible models and how to handle them properly :
Consent for the same accounts. The differences may be in scope or the time they are valid.
In the current model, the new consent for accounts BC will override the old one. All three accounts will be visible, but the A account will not be refreshed. In the edge scenario account B can have 5 consents which will exceed his daily limit of refreshes
The customer should be clearly informed if he is adding new consent and all ABC will be refreshed, or he will only have account C refreshed.
Should we keep the old AB consent? What if ABC is given for the same scope, but longer time?
Handling life cycle of consent
For each account, there are 2 specific attributes related to consent status. For a consent that includes 1+ accounts (aka consented accounts) the values for each account are provided by the same consent item in PSD2Hub.
consentStatus with 2 statuses:
0- the last usage of refresh token/ access token
1- the last usage of access token or refresh token failed
consentStatusReason - more detailed information based on ASPSP response (please refer to Handling responses from ASPSP section for more details on how ASPSP responses are analyzed). Value for each reason is defined by:
the point in the AIS session process where consentStatus has been invalidated (as on diagram below)
message from ASPSP (e.g. consent expired/ consent revoked)
list of consentStatusReason (dictionary will be confirmed):
refresh token rejected - technical error
refresh token rejected - invalid grant
refresh token rejected - expired
refresh token rejected - revoked
access token rejected - expired
access token rejected - revoked
access token rejected - technical error
