search

OpenBanking-Brasil / specs-seguranca

Documentação das especificações do GT de Segurança do Open Banking Brasil. As especificações ainda estão em versão draft e não devem ser utilizadas para implementação.
66 stars 46 forks source link

Consent life cycle #57

Closed carlosaaf closed 3 years ago

carlosaaf commented 3 years ago

In email was questioned

... The Consent API has a ‘Status’ but I couldn’t find anywhere the ‘Life Cycle’ of the Consent API was documented. The Consent API States should have the following states (or equivalent) Created – New Consent with no details yet populated by the Banks Customer. AwaitingAuthorisation – A user has authenticated with this scope / consent id and the user matches the TPP Asserted Identity so the Bank and TPP knows that the user has authenticated. The User has authorized the OAuth 2.0 flow but additional authorisation is required. (will be required for business payments). This state transition is optional Authorised – All necessary customers have authorised the access. Rejected – The user did not authorise the consent. Revoked – The customer revoked the consent at the Bank ...

This is response

According to the documentation (https://openbanking-brasil.github.io/areadesenvolvedor/#criar-novo-pedido-de-consentimento), when requesting the creation of consent and a response with return code 201 is returned (Created), a ResponseConsent is returned. In the ResponseConsent definition (https://openbanking-brasil.github.io/areadesenvolvedor/#tocS_ResponseConsent) the status field is an enumeration with the values ​​below:

Enumerated Values Name Code status AUTHORISED status AWAITING_AUTHORISATION status REJECTED status REVOKED

As a result, the life cycle follows the same pattern as in the UK (https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/aisp/account-access-consents.html#status-flow)

Diagram

RalphBragg commented 3 years ago

Hi,

The reason i raised this question is that the 'revoked' state was removed from the UK in 3.1.4. Consents are no longer Revoked they are simply deleted. TPPs and Only TPPs can clean up and manage consents which is why clarity on what approach and states you want to have?

Look at the table in documentation

-- | -- | -- 1 | Rejected | The account access consent has been rejected. 2 | AwaitingAuthorisation | The account access consent is awaiting authorisation. 3 | Authorised | The account access consent has been successfully authorised. 4 | Revoked | The account access consent has been revoked via the ASPSP interface. This status is not applicable for the resource created after Ver 3.1.4.

"The account access consent has been revoked via the ASPSP interface. This status is not applicable for the resource created after Ver 3.1.4."

This has a direct impact on both the 're-authorisation' and 'security profile' so clarity is requested asap.

Revoked was replaced with just 'deleted' i.e resource is no longer there. Which pattern do you want to follow?

DeiGratia33 commented 3 years ago

We have a question to be answered by the legal team. My concern we are not going to be allowed to delete. We need to store the consent after revoked, maybe for 5+1 years.

RalphBragg commented 3 years ago

Thanks - having a revoked state is perfectly fine just don't point people at the U.K. specs as this state has been deprecated.

Will adding this ticket to functional API.

RalphBragg commented 3 years ago

@DeiGratia33 - can this be closed?

DeiGratia33 commented 3 years ago

@RalphBragg , yes we can close.

RalphBragg commented 3 years ago

Do you have issue close rights?

DeiGratia33 commented 3 years ago

no, I am just a padawan

RalphBragg commented 3 years ago

@EkkeErick - can we get Alex and Marcos Administration access pretty please.