loggedUser and businessEntity constraints to AS

[ginglass]

Hello guys. I realize that we forgot to make clear on specs a constraint to require Authorization Server just permit authenticate a user that has the same CPF informed in loggedUser (document part) attribute present on linked consent resource object.

We also miss to establish a constraint to guarantee AS to check if the business account seleced or related to an authenticated user has the same value of an CNPJ that would be present in businessEntity element of a linked Consent Resource object.

like:

7. shall ensure authenticated user´s CPF number matches loggedUser CPF value
8. if CNPJ is present as a businessEntity element of a linked Consent Resource object, shall ensure that CNPJ related with an business account related to or selected by an authenticated user is the same

Don´t you agree @alex-siqueira and @DeiGratia33 ?

[DeiGratia33]

Agree. This piece of validation is missing from our specs.

[RalphBragg]

Technically this should be 'implicit' and obvious but it is a normative change in addition there was questions raised by the UI/UX team regarding the binding of Customer CNPJ accounts and how the matching should be performed.

e.g if i have an account and you have to specify each cnpj to the TPP first, if i'm trying to share say 3 different business accounts that would mean i have to login and authenticate and authorise 3 separate times (this cnpj isn't an array it's a single value). It makes sense for individual accounts to just require a single CPF but there's UI/UX issues that i thought still needed clarifying.

Likewise, there is actually additional checks that need to be added that are 'implicit' but perhaps should be explicit. These are the checks that we do.

1. We need to check that that the Consent Resource was owned by the Same Client.
2. We need to check that the Consent Resource (if using loggedUser) is owned by the same cpf.
3. We need to check that the CNPJ if provided is owned by the same user however.

a. If the organisation supports personal and business should the bank present a list of CPF (personal) account matches or only a list where CPF + CNPJ mathces? b. What happens if the CNPJ isn't an exact match but someone has correctly entered in a parent organisation Id? Is it an exact match for CNPJ or is it not. c. What happens if an account requires multi party authorisation. (I HIGHLY recommend that you get together and look at the requirements for potentially including the CNPJ on the consent response message). This would allow the TPP to know that the customer consented certain accounts to be shared but it is not yet fully Authorized. d. I haven't seen a state diagram that shows what the state of the authorisations are when a consent requires multi party authorisation to share. e. What if there are multiple accounts being shared but they have different authorisation requirements.

In the case of multi party authorisation, is it the TPP's responsibility to then get the second (or any additional users) to authenticate onto the platform. Should they be then reusing the same consent ID or is it the banks responsibility to source this additional consent? The consent API doesn't provide sufficient information to keep the TPP informed of all of the steps and potential processes that need to happen in order to address multi party for either retail or business.

I'd suggest splitting this issue up into separate tickets so they can be tackled a piece at a time starting with

1. We need to check that that the Consent Resource was owned by the Same Client.
2. We need to check that the Consent Resource (if using loggedUser) is owned by the same cpf.

The others are quite complex and will require an API change to solve holistically.

As an FYI, this is the same challenge that Australia is facing at the moment.

[danillobranco]

In this figure

(a) One CNPJ is controlled by 1 or any CPFs. This should be done regarding the SOCIAL CONTRACT (Contrato Social) or any public document that gives control to any CPF (Procurador Legal). The CPF must be identified by the CNPJ as a legal person who represent this CNPJ to share his DATA or in the situation (d), person that can do payments and transactions in the name of this CNPJ

(b) Is the CPF who have the legal power to consent the transmission of CNPJ data, that can be a legal representative or partner, anyway this should be explicit in some public document (check part a). And additionally, it must be clear if the person can do this consent alone, or in group, so the transmitter has to be aware if a CPF has enough power to consent the transmission alone, or if he should take another "consents" (Ralph cited this on C and D, as a multi party consent)

Forgot C

(d) One CNPJ can have multiple accounts, and for each account you can have someone who control this, but this person maybe don't have power to consent data, but have power to consent a payment, and is normal that his power have limits, like the total value of this payment

(e) In detail, a CPF can do payments regarding a specific account of a CNPJ, is normal that this persons is recognized as (Operator Number, or Operator ID), and this persons can do Payments anywhere, he just need to respect the limits. Some organization have multi party authorization for payments, so in this case, you command the initiation of payment, but you need to wait another consents, of another CPF, to complete the payment

Conclusion I don't think that the consent must change to accept CNPJ, because anyway it's a person who do the consent, and this person have a CPF, but we need to think how to control this. For instance, we do a state machine as Ralph said, regarding the situation of investments factory's in Brazil.

[ginglass]

Hi folks.

After some discuss with Specs, UX and PRC...

• loggedUser has to be filled with CPF of user logged at TTP (based on a previously made minimum registration process), even if it is related to a business acoount;
• if the businessEntity attribute is not filled in with the CNPJ, the user could only select/share data from the individual account he owns. Banks must restrict selection options.
• if filled in, he could only select/share account data related to the CNPJ (filled in by the TTP). So just one CNPJ will be returned at cnpj claim.
• If an user has more than one business account (related to another CNPJ) a new consent must be given.

The CPF and CNPJ information must be filled in by the TTP based on data from a minimum registration previously made.

[alexasensio]

Hi @ginglass, regarding your latest update:

• If the businessEntity is not filled in, and the user does not have any individual account on the sharing financial institution (only business accounts): During the authorization request, what is the expected error that needs to be sent to the receiving institution?
• Similarly, if the businessEntity if filled with a valid CNPJ, but the in the sharing financial institution the customer does not have access to that CNPJ (e.g.: wrong CNPJ): During the authorization request, what is the expected error that needs to be sent to the receiving insitution?

[RalphBragg]

@ginglass - can you take Alex's questions and pull them into a table of OIDC errors please.

• User didn't select any accounts
• Submitted Consent didn't belong to User
• Submitted Consent didn't belong to client (hijack)
• User CPF does not match consent
• CNPJ does not match consent
• User not authorized to share data on behalf of CPF.

All these errors should be given defined strings as error responses from the OP back to the Client.

I'm sure they'll be more - definitely worth a separate ticket.

[ginglass]

Great ideia. I´m going to ask for specs WG to do that and I´ll propose a PR to make that constraints clear on security profile.

[EkkeErick]

@RalphBragg , one question that rose about adding this was if it would impact the conformance Tests?

At the current moment i am supposing both Raidiam and OIDF engines won't check the return in case of those errors.

Best, Erick

[RalphBragg]

Hi,

It shouldn't at the moment however it would be useful to understand the specific tests cases that would have to be created.

Because this would result in an error being returned from the OP you will need to uplift the standards to cover the OP errors i mentioend earlier.

[ginglass]

Hi guys, change proposal to security profile to fix it:

https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID1.md#authorisation-life-cycle)

Authorisation Life Cycle (...)

8. shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC 6749) if the CPF of the authenticated user is not the same as indicated in the loggedUser element of the Consent Resource Object;
9. shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC 6749) if the businessEntity element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
10. an autenticated or selected business account´s CNPJ must match the value present in the businessEntity element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC 6749).

Portuguese version:

8. deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC 6749) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento loggedUser do Consentimento (Consent Resource Object);
9. deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC 6749) caso o elemento businessEntity não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento businessEntity do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC 6749).

Any suggest?

Regards,

[RalphBragg]

Seems fine but this is a normative change. Make an ID2 of all documents and incorporate.

We will then ask the oidf to make a ID2 conformance suite. It’s not critically urgent and there’s lots of other stuff that needs to go in. CIBA, consent api changes etc .

---

From: ginglass @.> Sent: Thursday, July 8, 2021 1:02:25 AM To: OpenBanking-Brasil/specs-seguranca @.> Cc: Ralph Bragg @.>; Mention @.> Subject: Re: [OpenBanking-Brasil/specs-seguranca] loggedUser and businessEntity constraints to AS (#118)

Hi guys, change proposal to security profile to fix it:

https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID1.md#authorisation-life-cycle)

Authorisation Life Cycle (...)

8. shall return authentication failure and return code access_denied in the error parameter (as specified in section 4.1.2.1 of RFC 6749) if the CPF of the authenticated user is not the same as indicated in the loggedUser element of the Consent Resource Object;
9. shall return authentication failure and return code access_denied in the error parameter (as specified in section 4.1.2.1 of RFC 6749) if the businessEntity element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
10. an autenticated or selected business account´s CNPJ must match the value present in the businessEntity element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code access_denied in the error parameter (as specified in section 4.1.2.1 of RFC 6749).

Portuguese version:

8. deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC 6749) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento loggedUser do Consentimento (Consent Resource Object);
9. deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC 6749) caso o elemento businessEntity não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento businessEntity do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC 6749).

Any suggest?

Regards,

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenBanking-Brasil/specs-seguranca/issues/118#issuecomment-876012631, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AILY5L3N4HDTMY6AJCRNLPDTWTTJDANCNFSM462ZSXAQ.