Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

  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 "AUTHORIZED". Para tokens gerados com o scope: 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 access_denied 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 access_denied 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.

...