openbanking-brasil / areadesenvolvedor Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://openbanking-brasil.github.io/areadesenvolvedor/
Home Page: https://openbanking-brasil.github.io/areadesenvolvedor/
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?
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 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
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.
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.
we ran the consent conformance tests and a few negative test cases failed
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.
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
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
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.
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.
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
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.
Prezados,
existe um erro digitação nesse repositório apontado pelo @lucas-azambuja.
Verificar PR fechada: #309
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.
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'
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
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
Toda comunicação máquina-a-máquina (m2m) usará mTLS, conforme RFC rfc8705 e detalhado na especificação de segurança:
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.
@@ -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.
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
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.
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.
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:
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!
At https://openid.net/specs/openid-financial-api-part-1-1_0-final.html#rfc.section.6.2.1
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?
This issue might belong to this group instead of on Security, so I am raising it here:
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?
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
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:
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:
Or only:
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?
Me parece valido criar um enumerador para a chave de permissions no CreateConsent, atualmente isso pode ser um array com qualquer string.
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.
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á :)
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?
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).
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'
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:
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.