Comparação de Páginas

...

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 Insurance 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. 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.

9. 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.

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

11. 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;

12. 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.

13. o valor do campo organizationIdentifier do certificado deve conter o prefixo correspondente ao Registration Reference OPIBR- seguido do valor do campo org_id do SSA.

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

15. deve garantir a integridade do estoque de consentimentos ativos, mesmo após eventuais mudanças sistêmicas, para que taís alterações sejam transparentes para as instituições receptora de dados.

16. deve realizar recertificação FAPI e DCR da OIDF após eventuais mudanças sistêmicas.

...

Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:

7.2 Funções regulatórias para mapeamentos OpenID e OAuth 2.0

...

A tabela a seguir descreve as funções regulatórias do Open Insurance e o mapeamento de escopos do OAuth 2.0 relacionado. Se os escopos forem omitidos durante o processo de DCR, o Servidor de Autorização deve conceder o conjunto completo de escopos potenciais com base nas funções regulatórias registradas para a seguradora, conforme descrito na seção Server Defaults.

É necessário validar as roles ativas no software_statement da aplicação. Na validação dessa informação deve ser utilizado o campo software_statement_roles, e deve ser verificado se as roles listadas estão ativas.

...