Comparação de Páginas

...

1. deve realizar a autenticação do cliente utilizando private_key_jwt;

2. deve exigir requisições do tipo "pushed authorization requests" PAR;

3. 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");

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

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

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

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

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

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

10. (requisito temporariamente retirado);

11. deve suportar refresh tokens;

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

13. deve sempre incluir a claim acr no id_token;

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

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

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

17. 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 haja clientes ativos;

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

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

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

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

21. deve exigir a utilização de Proof Key for Code Exchange (PKCE);

22. deve exigir a utilização do subject_type “public”;

23. deve exigir a utilização do response_mode “fragment”;

...

1. Deve obrigatoriamente criptografar o id_token retornado pelo authorization endpoint antes do envio ao cliente. O id_token retornado pelo token endpoint deve retornar sem criptografia..

2. Para a criptografia do id_token deve ser utilizada chave disponível no JWKS informado no parâmetro jwks_uri, com o atributo “use”:”enc”, durante o registro do cliente, indicada através do cabeçalho kid do documento JWT;

3. O uso de outros cabeçalhos para indicação da chave utilizada, como x5u, x5c, jku ou jkw é vetado conforme definido na cláusula 2 OIDC.

...

1. deve suportar objetos de solicitação encrypted;

2. deve suportar solicitações de autorização push (pushed authorization requests) PAR;deve usar objetos de solicitação encrypted se não usar PAR;

3. deve suportar o escopo de recurso OAuth 2.0 parametrizado consent conforme definido na cláusula 6.3.1 OIDF FAPI WG Lodging Intent Pattern;

4. deve suportar refresh tokens;

5. não deve incluir um valor específico na claim acr;

6. deve definir a claim acrcomo essential;

7. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da Financial-grade API Security Profile 1.0 - Part 2: Advanced incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não PAR - item 11);

8. não deve permitir o recurso de rotação de refresh tokens;não deve solicitar requisições de autenticação que incluam um id_token_hint, visto que o id_token a ser utilizado pode conter Informação de Identificação Pessoal, que poderia ser enviada descriptografada através do cliente público;

9. deve enviar o cabeçalho x-fapi-interaction-id em endpoints FAP

...