Comparação de Páginas

...

1. deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisições do tipo "pushed authorization requests" PAR;

2. deve publicar metadados de descoberta (incluindo a do endpoint de autorização) por meio do documento de metadado especificado em OIDD e [RFC8414] (".well-known");

3. deve suportar os parâmetros claims como definido no item 5.5 do OpenID Connect Core;

4. deve suportar o atributo claim padrão oidc "cpf" conforme definido no item Clarificações sobre a "sub" Claim deste documento;

5. deve suportar o atributo claim padrão oidc "cnpj" conforme definido no item Solicitando uma "claim" cpf deste documento, se a instituição for detentora de conta para pessoas jurídicas;

6. deve suportar o atributo acr "urn:brasil:openbanking:loa2" como definido no item Solicitando uma "claim" cnpj deste documento;

7. deveria suportar o atributo acr "urn:brasil:openbanking:loa3" como definido no item Solicitando uma "claim" cnpj deste documento;

8. deve implementar o endpoint "userinfo" como definido no item 5.3 do OpenID Connect Core;

9. deve suportar o escopo parametrizável ("parameterized OAuth 2.0 resource scope") consent como definido no item 6.3.1 de OIDF FAPI WG Lodging Intent Pattern;

10. pode suportar Financial-grade API: Client Initiated Backchannel Authentication Profile;

11. (requisito temporariamente retirado);

12. deve suportar refresh tokens;

13. deve emitir access tokens com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos;

14. deve sempre incluir a claim acr no id_token;

15. deve suportar os valores code e id_token para o atributo response_type;

16. pode suportar o valor code para o atributo response_typeem conjunto com o valor jwt para o atributo response_mode;

17. não deve permitir o recurso de rotação de refresh tokens;

18. deve garantir que em caso de compartilhamento do Servidor de Autorização para outros serviços, além do Open Finance, não divulgue e/ou possibilite o uso de métodos não certificados no ambiente do Open Finance;

19. deve garantir que as configurações divulgadas aos demais participantes através do OpenID Discovery (indicado pelo arquivo de Well-Known cadastrado no Diretório) sejam restritos aos modos de operação aos quais a instituição se certificou;

    1. deve manter em suas configurações os métodos para os quais ainda hajam clientes ativos;

    2. deve atualizar os cadastros que utilizem métodos não certificados, através de tratamento bilateral entre as instituições envolvidas;

       Âncora
       token_id token_id

20. deve recusar requisições, para o ambiente do Open Finance, que estejam fora dos modos de operação ao qual a instituição certificou seu Servidor de Autorização;

21. deve recusar requisições de autenticação que incluam um id_token_hint, visto que o id_token em posse do requisitante pode conter Informação de Identificação Pessoal, que poderia ser enviada descriptografada pelo cliente público;

22. o tempo mínimo de expiração do request_uri deve ser de 60 segundos;

23. deve recusar requisições que não apresentem o cabeçalho x-fapi-interaction-id em endpoints FAPI;

...

1. O receptor deve validar a consistência da assinatura digital da mensagem JWS exclusivamente com base nas informações obtidas do diretório, ou seja, com base nas chaves publicadas no JWKS da instituição no diretório.

2. As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no Padrão de Certificados Open Finance Brasil;

3. A claim iat deve ser numérica no formato Unix Time GMT+0 com tolerância de +/- 60 segundos;

4. A claim do jti deve ser única para um clientId dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 403. Demais casos seguir instrução da RFC 6749, item 5.2;

...