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 5.2.2.3;

6. deveria suportar o atributo acr "urn:brasil:openbanking:loa3" como definido no item 5.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 de recursos protegidos;

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”;

24. Deve emitir refresh_tokens exclusivamente do tipo opaco e (JWT ou opaco) sem prazo de validade associadonos cenários onde o mesmo é necessário.

5.2.2.1. Token de ID como assinatura separada

...

1. Deve obrigatoriamente criptografar o id_token nos momentos de call-back e chamada do endpoint de token;

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.

...

• alg - deve ser preenchido com o valor PS256";

• kid - deve ser obrigatoriamente preenchido com o valor do identificador da chave utilizado para a assinatura;typ - deve ser preenchido com o valor JWT.

• Em caso de erro na validação da assinatura pelo Provedor do Recurso a API deve retornar mensagem de erro HTTP com status code 400 e a resposta deve incluir na propriedade code do objeto de resposta de erro especificado na API (ResponseError) a indicação da falha com o conteúdo BAD_SIGNATURE.

• Erros na validação da mensagem recebida pela aplicação cliente (p. ex. iniciador de pagamento) devem ser registrados e o Provedor do Recurso (p. ex. instituição detentora de conta) deve ser notificado.

...