Comparação de Páginas

Prefácio

...

O Perfil de Segurança Financial-grade API 1.0 do Open Finance Brasil consiste nas seguintes partes:

• Open Finance Brasil Financial-grade API Security Profile 1.0

• Open Finance Brasil Dynamic Client Registration Profile 1.0

...

1. deve rejeitar as solicitações de registro de cliente dinâmico não realizadas em uma conexão protegida com mTLS usando certificados emitidos pelo Brasil ICP (produção) ou o Diretório de Participantes (sandbox);

2. deve validar que a solicitação contém software_statement JWT assinado usando o algoritmo PS256 emitido pelo Diretório de Participantes do Open Finance Brasil;

3. deve validar que o software_statement foi emitido (iat - issued at) não mais de 5 minutos antes do pedido ser recebido;

4. deve validar que um atributo jwks (definida por valor) não foi incluído, e sim declarado como referência no atributo jwks_uri;

5. deve, quando informado, validar que o jwks_uri corresponda ao software_jwks_uri fornecido na declaração do software;

6. deve exigir e validar que o redirect_uris corresponda ou contenha um subconjunto dos valores de software_redirect_uris fornecidos no software_statement;

7. deve exigir e validar que todos os mecanismos de autenticação de cliente cumpram os requisitos definidos nas RFC7591 e RFC7592, através da validação do registration_access_token e, como conexão segura, da cadeia de certificados confiáveis ICP-Brasil.

8. removido;

9. deve validar se os escopos solicitados são adequados para as permissões regulatórias autorizadas da instituição e contidas no _software_statement. A relação de permissões regulatórias e os escopos correspondentes está descrita nas seções a seguir.

10. deve, sempre que possível, validar os metadados declarados pelo cliente em relação aos metadados fornecidos no software_statement, adotando os valores presentes no SSA com precedência.

11. deve aceitar todos os nomes x.500 AttributeType definidas no Distinguished Name dos Perfis de Certificado x.509 definidos em Open Finance Brasil x.509 Certificate Standards;

12. se for compatível com o mecanismo de autenticação do cliente tls_client_auth, conforme definido em RFC8705, somente deve aceitar tls_client_auth_subject_dn como uma indicação do valor do atributo subject do certificado, conforme definido na cláusula 2.1.2 RFC8705;

13. O valor do campo UID do certificado deve coincidir com o enviado no SSA, onde o campo UID deve conter o valor do campo software_id do SSA.

14. O campo organizationIdentifier será encontrado no subject_DN em formato ASN.1 e deverá ser decodificado respeitando o string enconding correspondente. O valor do campo organizationIdentifier do certificado que deve conter o prefixo correspondente ao Registration Reference OFBBR- seguido do valor do campo org_id do SSA. Deve-se converter os valores do campo OID 2.5.4.97 do formato ASN.1 para texto legível para humanos. Para certificados emitidos até 31 de Agosto de 2022: o valor do campo OU do certificado deve conter o valor do campo org_id do SSA.

15. deve, durante o processo de handshake TLS, usar a regra distinguishedNameMatch para comparar os valores DN conforme definido na RFC4517.¶

16. deve ser garantido a todos, após os mesmos atos de consentimentos permanentes, para que também sejam alterados para instituições receptoras de dados transparentes (TPP).

17. deve realizar recertificação FAPI e DCR OIDF após eventuais alterações sistêmicas.

...

A cláusula 3 do Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names define os OIDs obrigatórios cujas as strings do AttributeType (descritores) devem ser reconhecidos pelos implementadores. Esta lista obrigatória não inclui vários dos OIDs definidosem Open Finance Brasil x.509 Certificate Standards, nem existe um mecanismo definido para os Servidores de Autorização publicarem informações sobre o formato que eles esperam de uma Solicitação Dinâmica de Registro do Cliente (Dynamic Client Registrarion) que inclui um tls_client_auth_subject_dn.

Para resolver essa ambiguidade, o Servidor de Autorização deve aceitar exclusivamente os AttributeType (descritores) definidas no último parágrafo da cláusula 3 RFC4514 em formato string,  também deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name Open Finance Brasil x.509 Certificate Standards ou adicionados pela Autoridade Certificadora.

Em caso de não atendimento destes requisitos o Servidor de Autorização deverá rejeitar o registro.

...

Emissor do Open Finance Open Finance Brasil SSA de sandbox

Sobre os mecanismos de autenticação e autorização dos serviços de DCR e DCM

Âncora
registro registro

Por serem serviços auxiliares ao fluxo principal do Open Finance Brasil, os serviços de registro e manutenção dinâmica de clientes não utilizam os mesmos mecanismos de controle de acesso. Por exemplo: não é possível exigir um access_token OAuth 2.0 de uma aplicação cliente que ainda não está registrada na instituição transmissora. Para estender as RFC7591 e RFC7592, que recomendam mecanismos mínimos para autenticação dos seus serviços, as instituições que suportam os fluxos de registro e manutenção dinâmica de clientes devem implementar em seus Servidores de Autorização os controles a seguir:

...

1. removido

2. validar a presença e a correspondência do header Bearer Authorization contendo o valor do atributo registration_access_token retornado durante o registro do cliente correspondente.

3. realizar as validações dos subitens 1, 3, 4 e 6 do item 9.3.1 Registro de cliente - POST /register.

Observação: A RFC7592 prevê a possibilidade de rotação do registration_access_token emitido pelo Servidor de Autorização a cada uso, tornando-o um token de uso único. As instituições devem considerar esse aspecto no registro de suas aplicações cliente para receber e atualizar o registration_access_token pelo novo valor recebido nas chamadas de manutenção de cliente.

...