openbanking-brasil / areadesenvolvedor Goto Github PK

We understand the /resources/v1/resources API is mandatory for all consents, alternatively the /customers/v1/personal/identifications could be used.

Please advise which should be used as the standard endpoint for conformance testing.

At https://openid.net/specs/openid-financial-api-part-1-1_0-final.html#rfc.section.6.2.1

11. must set the x-fapi-interaction-id response header to the value received from the corresponding FAPI client request header or to an RFC4122 UUID value if the request header was not provided to track the interaction, for example, x -fapi-interaction -id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a;

But at https://openbanking-brasil.github.io/areadesenvolvedor/#cabecalhos-http response headers,
the header (x-fapi-interaction-id) is not mandatory

which one should I consider?

Segundo a documentação alguns status http devem ser retornados da seguinte forma. Na documentação não fica claro quais os valores devo aplicar nos atributos code, title e detail.
Essa dúvida surge por conta do 422ResponseErrorCreateConsent onde temos a especificação desse valores. Como proceder nesses casos, alguém já passou por esse problema?

1. 422ResponseErrorCreateConsent

• https://openbanking-brasil.github.io/areadesenvolvedor/#tocS_422ResponseErrorCreateConsent

The specifications for the DateTimes are set to max length of 20.
This means that custom formatting and rounding needs to be applied to libraries that are pretty much generate https://datatracker.ietf.org/doc/html/rfc3339#section-5.6 standard messages out of the box.
See Here: https://gitlab.com/openid/conformance-suite/-/issues/916

Would suggest making this field 100% compliant with the Swagger type of RFC3339 and adjusting the 'max length' appropriately.

This issue might belong to this group instead of on Security, so I am raising it here:

OpenBanking-Brasil/specs-seguranca#146

we ran the consent conformance tests and a few negative test cases failed

1. The test sent this to the consent request
   {"data":{"permissions":["CREDIT_CARDS_ACCOUNTS_BILLS_READ","CREDIT_CARDS_ACCOUNTS_READ","RESOURCES_READ"],"loggedUser":{"document":{"identification":"12345678901","rel":"CPF"}},"businessEntity":{"document":{"identification":"12345678901123","rel":"CNPJ"}},"expirationDateTime":"2021-07-23T23:36:34Z"}}

Test expected a failure but our solution returned a pass.
What is the correct combination to validate the permission set. If we can be pointed to the correct requirement we can look at implementing it.

2. The test sent this to the consent request
   {"data":{"permissions":["ACCOUNTS_READ","ACCOUNTS_BALANCES_READ","RESOURCES_READ"],"loggedUser":{"document":{"identification":"12345678901","rel":"CPF"}},"businessEntity":{"document":{"identification":"12345678901123","rel":"CNPJ"}},"expirationDateTime":"2021-07-23T22:26:41Z"}}

Again the solution accepted it but the test was expecting a 403 error. The test failed with this error

EnsureResponseFromConsentApiWas403

Something unexpected happened (this could be caused by something you did wrong, or it may be an issue in the test suite - please review the instructions and your configuration, if you still see a problem please contact [email protected] with the full details) - couldn't find required object in environment before evaluation: errored_response

Procurei pelos assets de marca na documentação e nos repositórios, mas não achei. Porém a marca aparece em vários lugares no site institucional.

Existe algum "manual da marca", "guia de estilo" ou até algum arquivo SVG do logo publicamente? Se não é público, como consigo esses assets?
Vi no repositório que existe um PNG, mas ele é branco (e é png).

Hello,
I think there's an error at the documentation for the endpoint POST /payments/v1/consents.
At the bottom the this method, there's a red box describing the necessary scopes to call this method:

It's says:

• openid
• consent:consentId
• payments

As it's the creation of the consent, the caller doesn't have the consentId, so it's not possible to pass this scope, I think the right scopes should be:

• consents
• payments

Or only:

• payments

Olá :)

Dúvida: O item RESOURCES_READ deveria estar listado em https://github.com/OpenBanking-Brasil/areadesenvolvedor/blob/master/documentation/source/dictionary/consents_list.csv ? 🤔

Além disso, temos os seguintes resultados:

• 7 resultados para RESOURCES_READ
  https://github.com/OpenBanking-Brasil/areadesenvolvedor/search?q=RESOURCES_READ

• 14 para ACCOUNTS_READ
  https://github.com/OpenBanking-Brasil/areadesenvolvedor/search?q=ACCOUNTS_READ

O RESOURCES_READ é de alguma categoria/hierarquia diferente?

Me parece valido criar um enumerador para a chave de permissions no CreateConsent, atualmente isso pode ser um array com qualquer string.

personal_identification.csv
data/nationality/otherNationalitiesInfo

Situação atual:
string (40)

Proposta:
converter para: array of string(3)

Motivação:
Não está claro qual a padronização de separação de múltiplas ocorrências quando a pessoa for aplicável a várias nacionalidades, se será com vírgula sem espacos, vírgula com espaços ou somente espaços.

Oi pessoal, eu estava lendo a documentação para o endpoint de obtenção das transações de uma conta e notei uma diferença entre o exemplo e a própria especificação:

exemplo
especificação

Sendo mais específico, a diferença se dá nos campos de beneficiário (Payee), que estão existente no exemplo mas não estão na especificação.
Gostaria de saber se esses campos serão incluídos no futuro ou se a especificação está desatualizada.

Obrigado!

Estou tentando encontrar uma resposta para isso mas ainda não consegui. Eu como desenvolvedor consigo acessar o open banking para um aplicativo de finanças pessoais? Verifiquei que tem empresas que tem acesso como https://www.pluggy.ai/ Como funciona isso?

https://openbanking-brasil.github.io/areadesenvolvedor/#saldos-da-conta
https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_accounts_apis.yaml

    availableAmount:
      type: number
      format: double
      pattern: '(-?\d{15}(.\d{4}?))$'
      description: 'Saldo disponível para utilização imediata. No caso de conta de depósito a vista, sem considerar cheque especial e investimentos atrelados a conta. Admite saldo negativo. Expresso em valor monetário com 4 casas decimais.'
      maxLength: 19
      minLength: 0
      nullable: true
      example: 100000.04

pattern does not correspond to double format and to example specified

At the end of Github's DELETE /consents API specification it mentions that " This operation does not require authentication".

However the swagger requires an access token:

This is more in line with what is expected, and it follows the same authentication requirements than the POST and GET methods.

1. Is the swagger correct and therefore in Github there is an errata?
2. If so, can we assume that the required scope for DELETE /consents is also "consents"?

Hi!

Only ACCEPTED_SETTLEMENT_COMPLETED_DEBITOR_ACCOUNT payment status uses "i" in "debtor" word. I think that it should be ACCEPTED_SETTLEMENT_COMPLETED_DEBTOR_ACCOUNT to maintain consistency across the documentation.

Url: https://openbanking-brasil.github.io/areadesenvolvedor/#tocS_ResponsePixPaymentData

Olá pessoal.

Estava explorando as APIs da fase 2, e vi que existe uma API de operações de crédito. Os gets das apis pedem um contractId, que eu entendi que temos que pegar do ipocCode depois de um parse neste campo.
O que eu não encontrei foi como pegar a lista de contratos de uma pessoa jurídica ou de uma pessoa física. Sei que ainda estão trabalhando nas especificações, mas não entendi como chegar no contrato se não tenho como recuperar esta informação de outro endpoint.

Por favor, podem esclarecer este ponto, e me corrigir se eu estiver errado?

Obrigado.

Pelo o que tenho me informado as APIs não são muito úteis para pessoas físicas.

Em algum momento APIs serão disponibilizadas para automação de operações bancárias?

The example latitude and long are outside of the valid ranges.
Given that these are numbers they should be any valid number to 11 decimals between -90 and +90 or -180 and + 180
https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_customers_apis.yaml

GeographicCoordinates:
type: object
description: 'Conjunto de informações, que correspondem aos valores das coordenadas geográficas em graus decimais, no Sistema de referência WGS84'
properties:
latitude:
description: |
Informação da Latitude referente a geolocalização informada. Entre -90 e 90.p.ex. '-90.8365180'. (2 casas antes da vírgula, 11 posições)
type: string
pattern: '^-?\d{1,2}.\d{1,9}$'
maxLength: 13
example: '-90.8365180'
longitude:
description: |
Informação da Longitude referente a geolocalização informada. Entre -180 e 180. p.ex '-180.836519.' (3 casas antes da vírgula, 11 posições)
type: string
pattern: '^-?\d{1,3}.\d{1,8}$'
maxLength: 13
example: '-180.836519'

The PriceInterval Enum states that service fees should be expressed as 1_FAIXA, 2_FAIXA and so on.

However, the Personal Accounts response example is showing it like 1_FAIXA_VALOR and 2_FAIXA_VALOR.

Some financial institutions like Bradesco are wrongly returning it in most of their services, eg:
https://api.bradesco.com/bradesco/open-banking/products-services/v1/personal-accounts
https://api.bradesco.com/bradesco/open-banking/products-services/v1/business-unarranged-account-overdraft

Original ticket: OpenBanking-Brasil/specs-seguranca#99

The transaction date filters defined in consent seem to only be documented in the consent swagger definition - the description is not definitive enough for people to understand. I can't find any more guidance to point people to for this requirement.

"transactionFromDateTime": "2021-01-01T00:00:00Z",
"transactionToDateTime": "2021-02-01T23:59:59Z"

Are these in scope? We assume they are, they are in the consent spec - if so, we need more documentation to describe the general concepts of both consent transaction date filters and transaction API date filters.

Olá pessoal,

Para a fase 2, os cabeçalhos FAPI devem ser informados pela camada do API Gateway ou do Identity Provider, ou podem ser de ambos?

Como vocês recomendam esta tratativa dos cabeçalhos?

Atenciosamente

Estou usando o e-mail da minha empresa com domínio sensorial.systems, porém suspeito que as regras de filtro não permitem.
Também tentei usar meu e-mail pessoal gmail.com, mas recebo uma mensagem dizendo que e-mails pessoais não são permitidos.

https://auth.directory.openbankingbrasil.org.br/interaction/c8lTLEe6_WgzZ_XCEdSEn

In the following documentation
https://openbanking-brasil.github.io/areadesenvolvedor/#tocS_ResponsePaymentConsent
The word AUTHORIZED is used, however, the correct spelling of this status is AUTHORISED with a 'S'

Prezados,

existe um erro digitação nesse repositório apontado pelo @lucas-azambuja.

Verificar PR fechada: #309

Hello friends, I found a small discrepancy regarding the endpoint.
get /accounts/{accountId}/transactions:

In the file documentation/source/swagger/parts/_open_banking_fase2_apis_part.yml
It has the following parameters:

• accountsCompeCode
• accountsBranchCode
• accountsNumber
• accountsCheckDigit

However, in the file documentation/source/swagger/parts/_accounts_apis_part.yml , the same endpoint doesn't have the parameters.

Can you tell me which is the most up-to-date file?

Looking at all APIs we have on the response headers that the x-fapi-interaction-id field lacks the property required: true, which is wrong as according to the item 6.2.12.11 on the FAPI 1 Specifications, which says:

6.2.1.11: Shall set the response header x-fapi-interaction-id to the value received from the corresponding FAPI client request header or to a RFC4122 UUID value if the request header was not provided to track the interaction, e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a;

The reference might be found on: https://openid.net/specs/openid-financial-api-part-1-1_0.html

This means that all of the APIs should be adapted to contain the required:true for the x-fapi-interaction-id on it's response.

The impact of this change is very low as most banks are already following the FAPI 1.0 and are already sending this on their headers.

This issue has been raised via service desk and the correction has been proposed by RalphBragg.

I need an Ok from the security WG to continue with the Specs Change together with Sensedia.

Foi definido que os dados de operações de crédito poderão ter até 1h de delay técnico entre o tempo de disponibilizar no melhor canal eletrônico da IF e o tempo de disponibilizar na API.
Contudo, existem modalidades de crédito ou até mesmo conjunto de dados de algumas modalidades que não estão disponíveis em nenhum canal eletrônico da instituição.

Neste caso, o delay permitido de 1h será referente a o que? Qual regra deve ser aplicado neste cenário?

diff --git a/documentation/source/includes/partials_open_banking/_open_banking_fase3_apis.md.erb b/documentation/source/includes/partials_open_banking/_open_banking_fase3_apis.md.erb
index c9c2c94e..ec2ae959 100644
--- a/documentation/source/includes/partials_open_banking/_open_banking_fase3_apis.md.erb
+++ b/documentation/source/includes/partials_open_banking/_open_banking_fase3_apis.md.erb
@@ -134,11 +134,11 @@ A iniciadora não deve usar comportamento idempotente do POST para pesquisar o s

Estabelece TLS

Toda comunicação máquina-a-máquina (m2m) usará mTLS, conforme RFC rfc8705 e detalhado na especificação de segurança:

• Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 1.

• Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3.

POST /tokens - Pedido de access_token e scope: payments, openid

Antes de começar o fluxo de iniciação de pagamento, a Instituição Iniciadora deverá ter se cadastrado como client na Instituição Detentora da Conta, em acordo com o especificado para o Registro Dinâmico de -Open Banking Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 1.
+Open Banking Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 2.
Uma vez cadastrada, a Instituição Iniciadora deverá obter o token de acesso (access_token) pelo fluxo de client credentials, conforme especificado pela RFC 6749 (rfc6749), com os escopos payments e openid.

Valida certificado SSL e scopes

@@ -227,7 +227,7 @@ Para evitar vazamento de informação, a detentora deve validar que o pagamento

No contexto da API Payment Initiation, os payloads de mensagem de consentimento e de pagamento que trafegam tanto por parte da instituição iniciadora de transação de pagamento quanto por parte da instituição detentora de conta devem estar assinados. Abaixo temos as orientações para assinatura das mensagens JWS.

-Informações complementares de segurança podem ser consultadas em https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID2-ptbr.md.
+Informações complementares de segurança podem ser consultadas em https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID3-ptbr.md.

• Passo 1 - Identifique a chave privada e o certificado de assinatura correspondente a serem usados para assinatura:

diff --git a/documentation/source/includes/partials_security_guide/_dynamic_client_registration.md.erb b/documentation/source/includes/partials_security_guide/_dynamic_client_registration.md.erb
index 636574ff..b86c8b4f 100644
--- a/documentation/source/includes/partials_security_guide/_dynamic_client_registration.md.erb
+++ b/documentation/source/includes/partials_security_guide/_dynamic_client_registration.md.erb
@@ -6,4 +6,4 @@ Os detalhes das especificações devem ser consultadas nos endereços:

https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html (em português).

-https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html (em inglês).
+https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html (em inglês).
diff --git a/documentation/source/includes/partials_security_guide/_signatures.md.erb b/documentation/source/includes/partials_security_guide/_signatures.md.erb
index 89db40b9..20c9010d 100644
--- a/documentation/source/includes/partials_security_guide/_signatures.md.erb
+++ b/documentation/source/includes/partials_security_guide/_signatures.md.erb
@@ -3,6 +3,6 @@
Sobre os certificados exigidos para assinatura de mensagens - Padrões de certificados digitais Open Banking Brasil:
https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1.md#certificado-de-assinatura-certificadoassinatura

-Sobre os algoritmos usados para assinatura de mensagens JWS - Perfil de segurança FAPI - Open Banking Brasil: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID1.md#algorithm-considerations
+Sobre os algoritmos usados para assinatura de mensagens JWS - Perfil de segurança FAPI - Open Banking Brasil: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID3.md#algorithm-considerations

Sobre mensagens assinadas, JWS e JWKS - Guia de usuário (Receptoras e iniciadoras de pagamento): https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/tpp-user-guide.md#143-what-is-a-jwt-jwe-jws-and-jwk
\ No newline at end of file

I'm re-opening this:
#158

@GislaineAlmeida the response you gave is not clear. As an ASPSP, it's not clear if these fields need to be built? Will they be part of the conformance tests? If we do need to build them, then we need a description of how to build them.

Current swagger for the Consent API (1.0.0-rc6.7) https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_consents_apis.yaml makes reference to a file mapping the relationship between Roles, scopes and permissions ("O arquivo com o mapeamento completo entre Roles, scopes e permissions está disponibilizado no Portal do desenvolvedor, no mesmo item acima - descrição do fluxo de consentimento.")

However, I can not find a link to it in Github (current version is 1.0.0-rc6.9), and my understanding is that it got deleted in the update to rc6.6. The last time I saw it linked is on rc6.5: https://openbanking-brasil.github.io/areadesenvolvedor/versions/v1.0.0-rc6.5/index.html#em-revisao-fluxo-de-consentimento: "A tabela de scopes e permissions pode ser vista aqui."

This file, as far as I know, is here: https://github.com/OpenBanking-Brasil/areadesenvolvedor/blob/196bf4779a6a7ce5b651193e68fa77c09e217619/documents/Mapeamento_roles_permissions.xlsx

1. Is that spreadsheet still valid today?
2. If that is the case, I think it is bad practice to have this information in a spreadsheet in a separate file, as any change to it gets lost and not tracked. Can this information be included in the last version for better visibility?

Current swagger of APIs related to the first phase of Open Banking project named swagger_open_banking_fase1_apis.yml has an inconsistency which prevents validation procedures (like with jsonschema validator) between the swagger and online APIs.

The identified inconsistencies are as follows:
In the PersonalLoan section, we have 5 required fields, one of them being: "interestRate".
In the properties subsection of PersonalLoan section, the field is named as "interestRates" (with a S at the end of the word).

The same problem happens in the BusinessLoan, BusinessUnarrangedAccountOverdraft, and PersonalUnarrangedAccountOverdraft sections.

In the LoanService section, we have 7 required fields, one of them being: "customers".
In the properties subsection of LoanService section, there is no reference for the required field "customers".

The same happens in the FinancingService and PersonalInvoiceFinancingsInterestRates sections.