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 5.2.2.2 Clarificações sobre a "sub" Claim deste documento;

5. deve suportar o atributo claim padrão oidc "cnpj" conforme definido no item 5.2.2.3 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 5.2.2.4 deste documento;

7. deveria suportar o atributo acr "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 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. não deveria retornar Informação de Identificação Pessoal (PII) confidenciais no token de ID na resposta de autorização, mas se for necessário, então ele deve criptografar o token de ID.

2. Informação de Identificação Pessoal pode incluir, mas não está restrito a:

   1. Claim sub caso use informação que possibilite a identificação da pessoa natural;

   2. As Claims padrões definidas na cláusula 5.1 OIDC, que podem conter dados como data de nascimento, endereço ou telefone;

   3. A nova Claim CPF, definida na próxima seção.

3. Caso seja solicitada alguma Claim contendo Informação de Identificação Pessoal:

   1. Se esta for marcada como essencial, em não se havendo chave de criptografia registrada para o Cliente, deverá falhar a requisição se for solicitada no Endpoint de Autorização. Não há impedimentos caso a solicitação seja feita pelo Cliente Confidencial através do Endpoint de Token;

      Âncora
      clarificacoes clarificacoes

   2. Se esta não for marcada como essencial, o Servidor de Autorização deverá omiti-la no Endpoint de Autorização, podendo ser respondida no Endpoint de Token chamado pelo Cliente Confidencial.

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

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

...