Comparação de Páginas

Prefácio

The normative version in English

...

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 (JWT ou opaco) sem prazo de validade nos cenários onde o mesmo é necessário.

...

• aud (na requisição JWT): o Provedor do Recurso (p. ex. a instituição detentora da conta) deverá validar se o valor do campo aud coincide com o endpoint sendo acionado;

• aud (na resposta JWT): o cliente da API (p. e. instituição iniciadora) deverá validar se o valor do campo aud coincide com o seu próprio organisationId listado no diretório;

• iss (na requisição JWT e na resposta JWT): o receptor da mensagem deverá validar se o valor do campo iss coincide com o organisationId do emissor;

• jti (na requisição JWT e na resposta JWT): o valor do campo jti deverá ser preenchido com o UUID definido pela instituição de acordo com a [RFC4122] usando o versão 4;

• iat (na requisição JWT e na resposta JWT): o valor do campo iat deverá ser preenchido com horário da geração da mensagem e de acordo com o padrão estabelecido na RFC7519 para o formato NumericDate.

• cty (na requisição JWT e na resposta JWT): o valor do campo cty deverá ser preenchido caso as operações de assinatura ou criptografia aninhadas não sejam empregadas, o uso desse parâmetro de cabeçalho não é recomendado. No caso de assinatura aninhada ou criptografia ser empregada, este parâmetro de cabeçalho deve estar presente; neste caso, o valor deve ser "JWT", para indicar que um JWT aninhado é transportado neste JWT. Embora os nomes dos tipos de mídia não diferenciem maiúsculas de minúsculas, é recomendável que "JWT" sempre seja escrito com caracteres maiúsculos para compatibilidade com implementações herdadas.

...

Este perfil define o escopo dinâmico do OAuth 2.0 "consentimento" da seguinte maneira:

• string 'consent'consent’ ou ‘recurring-consent’; e

• delimitador de dois pontos ":"; e

• Consent API REST Resource Id retornado por uma criação bem-sucedida de Open Finance Consent Resource;

Adicionalmente:

• Consent Resource Id deve incluir caracteres seguros para url;

• Consent Resource Id deve ser "namespaced";

• Consent Resource Id deve ter propriedades de um nonce Nonce;

...

1. deve apenas emitir refresh_tokens quando vinculados a um consentimento ativo e válido;

   1. Não deve emitir refresh_token quando o consentimento estiver no status “CONSUMED” (para fase 3);

   2. Deve emitir um access_token por meio de um grant_type do tipo client credentials no status “CONSUMED” (para fase 3).

2. só deve compartilhar o acesso aos recursos quando apresentado access_token vinculado a um consentimento ativo e com o status "AUTHORISED“. Para tokens gerados com o scope: payments ou recurring-payments, o status do consentimento não será validado.;

   1. No cenário de recebimento de token inválido, deve ser retornado status code 401.

3. deve revogar os refresh tokens e, quando aplicável, os access tokens quando o Consentimento (Consent Resource) relacionado for apagado;

4. deve garantir que os access tokens são emitidos com os scopes necessários para permitir acesso aos dados especificados em elemento Permission do Consentimento (Consent Resource Object) relacionado;

5. não deve rejeitar pedido de autorização com scopes além do necessário para permitir acesso a dados definidos em elemento Permission do Consentimento (Consent Resource Object) relacionado;

6. pode reduzir o escopo solicitado para um nível que seja suficiente para permitir o acesso aos dados definidos em elemento Permission do Consentimento (Consent Resource Object) relacionado;

7. deve manter registros sobre o histórico dos consentimento para permitir a adequada formação de trilhas de auditoria em conformidade com a regulação em vigor;

8. deve retornar falha na autenticação e o código de retorno _accessdenied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento loggedUser do Consentimento (Consent Resource Object);

9. deve retornar falha na autenticação e o código de retorno _accessdenied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749) caso o elemento businessEntity não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);

10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento businessEntity do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno access_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749);

11. deve emitir refresh_token com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.

...