Fase 3 - 1º Ciclo já está em vigorEnvio de Certificados IntermediáriosProibição da rotação do refresh tokenRecertificação DCR/DCM para instituições que obtiveram a certificação DCR antes do congelamento de 21/10Fase 3 – IdempotênciaFase 3 – Tratativa d...

Fase 3 - 1º Ciclo já está em vigor

O Banco Central esclareceu que a Fase 3 - 1º Ciclo entrou em vigor hoje, 29/10/2021.

Segundo recomendações do Regulador, as instituições participantes devem envidar esforços para resolver todas as pendências técnicas urgentemente.

O Conselho Deliberativo do Open Banking Brasil deliberou hoje pela criação de uma força tarefa com membros da Estrutura Inicial para resolver todas as pendências técnicas em aberto, viabilizando a correta operação da Fase 3.

Envio de Certificados Intermediários

O documento padrão de certificados foi ajustado em seu item 5.2.1, com o objetivo de reforçar a obrigatoriedade de envio da cadeia de certificados intermediários por parte dos servidores TLS conforme definido na RFC 5246. Solicitamos aos participantes que revisem as configurações de seus respectivos servidores.

Proibição da rotação do refresh token

O Conselho Deliberativo do Open Banking Brasil aprovou por unanimidade pela proibição da rotação do refresh token, devido ao risco verificado de perda de consentimentos e pelo entendimento de que a proibição da rotação não traz prejuízos significativos de segurança.

Foi dado o prazo de 30 dias para que as instituições se adequem a esta mudança, ou seja, até o dia 28/11/2021. Entendemos o impacto que isso pode ter em algumas instituições e pedimos para que nos informe através do e-mail do Secretariado caso este prazo não seja suficiente para o atendimento desse requerimento.

Clique aqui para enviar um e-mail ao Secretariado Open Banking

Recertificação DCR/DCM para instituições que obtiveram a certificação DCR antes do congelamento de 21/10

Em votação unânime em sua 87ª reunião ordinária, o Conselho Deliberativo do Open Banking deliberou sobre as recertificações de segurança dos módulos DCR/DCM das instituições que já haviam se certificado antes do congelamento, ocorrido de 30/09/2021 a 20/10/2021.

As orientações são:

- Todas as instituições entrantes na Fase 2 que obtiveram seu certificado antes do congelamento dos testes deverão se recertificar até 30/11/2021. Para esses casos, o certificado atual será válido até essa data.

- Todas as instituições entrantes na Fase 3 que obtiveram seu certificado antes do congelamento dos testes precisam se recertificar antes de entrar em produção para a Fase 3A - 1º Ciclo.

Reiteramos que não há custo para que as instituições obtenham a recertificação de segurança DCR/DCM. Esse custo foi absorvido pelo ecossistema do Open Banking. Para obter a isenção da taxa de recertificação é importante que as instituições mencionem nas suas submissões junto à OpenID Foundation que se trata de uma recertificação dos módulos DCR/DCM.

Clique aqui para solicitar a certificação da OpenID Foundation

Fase 3 – Idempotência

A seção de Fase 3 na área do desenvolvedor será alterada com a adição de novos textos sobre idempotência em 01/11. Este informe tem como objetivo adiantar os textos que serão inclusos no portal, enriquecendo três seções para a Fase 3A do Open Banking Brasil:

Assinatura de Mensagem vs Idempotência

Como assinar o payload

Idempotência

Assinatura de Mensagem vs Idempotência

O claim jti inserido dentro do JWT da assinatura da mensagem tem como objetivo evitar ataques de repetição e não é utilizado para o controle da idempotência. Desta forma, ele deverá ser gerado a cada nova requisição realizada às APIs, independentemente desta ser a requisição para a criação de uma nova operação ou ser a requisição para confirmação de execução de uma operação anterior (idempotente).

As validações referentes a assinatura de mensagens devem preceder as validações de idempotência.

Como assinar o payload

"*Texto inicial desta seção permanece inalterado. A partir da segunda tabela, a seguinte redação passa a valer imediatamente: "

Nome
Tipo
Obrigatório
Descrição

aud
string
true
(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.

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

iss
string
true
(requisição JWT e resposta JWT): o receptor da mensagem deverá validar se o valor do campo iss coincide com o organisationId da outra parte listado no diretório.

jti
string
true
(requisição JWT e resposta JWT): o valor do campo jti deverá ser preenchido com o UUID definido pela instituição de acordo com a RFC 4122 usando o versão 4.

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

A claim iat deverá ser gerada no Unix Time GMT +0 e sua verificação deverá possuir uma tolerância de +/- 60 segundos para cobrir pequenas diferenças nos relógios dos servidores dos participantes.

A claim do “jti” deve ser única para um clientId dentro de um intervalo de tempo de 86.400 segundos, não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 403.

As validações referentes às claims do JWT devem preceder a validação de idempotência (e.g. “jti”, “iat” e “iss”)

Idempotência

Segundo a W3C, "um método HTTP idempotente é um método HTTP que pode ser chamado muitas vezes sem resultados diferentes ou efeitos colaterais. Não importa se o método é chamado apenas uma vez ou dez vezes. O resultado deve ser o mesmo. Essencialmente, significa que o resultado de uma solicitação executada com sucesso é independente do número de vezes que ela é executada. Por exemplo, na aritmética, adicionar zero a um número é uma operação idempotente."

Os conhecidos métodos GET, PUT e DELETE são naturalmente idempotentes, assim como HEAD, OPTIONS e TRACE também são.

Porém, o método POST requer um tratamento especial para que se torne idempotente e, por estarmos tratando aqui de meios de pagamentos, fazer esse tratamento é algo desejável para que não ocorram acidentes.

Por que é necessário tratarmos a Idempotência do POST?

Imagine que seja realizado um POST de pagamento e, depois de alguns segundos, é retornada uma mensagem de Timeout. Nesse caso, não é possível saber se o POST foi efetivo e enviar o POST novamente, sem tratar a idempotência, poderá ocasionar em duplicidade de pagamento.

Como mitigarmos esse risco?

Do lado da iniciadora do pagamento: É necessário que seja enviado o POST com um GUID de Idempotência. Caso o mesmo POST seja reenviado por acidente ou precise ser reenviado, por qualquer motivo que seja, basta reenviar o POST com o mesmo GUID de Idempotência.

Do lado da detentora da conta: É necessário validar o GUID de Idempotência recebido. Caso tenha recebido o mesmo GUID de Idempotência, a nova mensagem de POST deverá ser descartada.

Importante reforçar que cada nova transação com POST deverá ter um novo GUID de Idempotência.

A iniciadora não deve usar comportamento idempotente do POST para pesquisar o status dos recursos.

Conjunto inicial de regras propostas na aplicação da idempotência:

A iniciadora/TPP não deve alterar o corpo da solicitação ao usar a mesma chave de idempotência. Se a iniciadora alterar o corpo da solicitação, a detentora/ASPSP não deve modificar o recurso final. A detentora pode tratar este caso como uma ação fraudulenta.

A detentora não deve criar um novo recurso para uma solicitação POST se estiver determinada como uma solicitação idempotente.

Na criação a detentora deve responder à solicitação com o status atual do recurso (ou um status que seja pelo menos tão atual quanto o que estiver disponível nos canais eletrônicos existentes) e um código de status HTTP 201 (CREATED).

A iniciadora não deve usar comportamento idempotente para pesquisar o status dos recursos.

A detentora pode usar a assinatura da mensagem, junto com a chave de idempotência, para garantir que o corpo da solicitação não seja alterado.

Para a API de Iniciação de Pagamento, a chave de idempotência deverá ser armazenada para controle quando a requisição for processada com sucesso (HTTP Status 201) ou quando ocorrer um erro de negócio (HTTP Status 422).

Para a API Consentimento de Pagamento, a chave de idempotência deverá ser armazenada para controle quando a requisição for processada com sucesso (HTTP Status 201).

O comportamento idempotente deve ser mantido por 24 horas para uma mesma chave de idempotência.

Toda nova requisição exige que a assinatura da mensagem seja refeita, contendo um novo jti e iat.

Cenários de uso de idempotência

Ao receber uma requisição com o mesmo x-idempotency-key e com a claim data do JWT com conteúdo idêntico ao da requisição original, a requisição deverá ser processada entregando o mesmo resultado obtido anteriormente. Isso significa que, caso a requisição inicial tenha criado um recurso, este mesmo recurso deverá ser retornado, com seu status atualizado.

Ao receber uma requisição com o mesmo x-idempotency-key e com a claim data do JWT com conteúdo diferente do original a requisição deverá ser recusada com o HTTP Status 422 com código NAO_INFORMADO.

Ao receber uma requisição com o mesmo x-idempotency-key e com a claim iss não pertencente a organização que possui o software cliente (clientId) a requisição deve ser recusada com o HTTP Status 403.

Fase 3 – Tratativa de erros de validação no DICT em cenários assíncronos

Para a API Fase 3, detalha-se a seguir o comportamento da validação do DICT:

Consulta ao DICT realizada pela detentora é obrigatória quando o localInstrument for igual a DICT, INIC, QRDN ou QRES. No entanto, ela possui flexibilidade para escolher em que momento a consulta deverá ser executada:

API DE POST/CONSENTS PODE TER A CONSULTA DO DICT

Caso a detentora opte por essa validação, esta validação deve ser síncrona.

Síncrono: retorno erro HTTP 422, código retornado DETALHE_PGTO_INVALIDO.

API DE POST/PAYMENTS PODE TER A CONSULTA DO DICT

Síncrono: retorno erro HTTP 422, código retornado BENEFICIARIO_INCOMPATIVEL.

Assíncrono: retorno erro HTTP 201, com status de pagamento PDNG ou PART.

API DE GET/CONSENTS DEVE PREVER O ERRO DE VALIDAÇÃO

Não será previsto retorno (específico para DICT inválido).

API DE GET/PAYMENTS DEVE PREVER O ERRO DE VALIDAÇÃO

Retorno erro HTTP 200, status REJECTED:

ELEMENT_CONTENT_FORMALLY_INCORRECT - Elemento da mensagem incorreto (CH16).

Comportamento do motor de teste:

Tempo de pooling 30 segundos com tempo máximo de 5 minutos

Além disso, será incluído em 01/11 na planilha de problemas conhecidos Fase 3 o seguinte ponto:

API/Sessão: API Payments / Schema EnumRejectionReasonType

Endpoint: GET /payments/v1/pix/payments/{paymentId}

Campo: rejectionReason

Qual o problema: Não está previsto uma opção específica no domínio de razões de rejeição para o cenário de validação de forma assíncrona da chave no DICT, quando os dados da conta do destinatário enviadas pela iniciadora não corresponderem aos dados da chave pix consultada no DICT ou chave pix inválida

Como deveria ser: Deveria estar definido uma opção específica no domínio de Razões de Rejeição (EnumRejectionReasonType) para essa situação

Orientação: Utilizar a opção ELEMENT_CONTENT_FORMALLY_INCORRECT para a situação do problema, na validação de forma assíncrona

Fase 3 – Padronização de fuso horário para o campo date

Será incluído em 01/11 na planilha de problemas conhecidos Fase 3 o seguinte ponto:

API/Sessão: API Payments / Schema PaymentConsent

Endpoint: POST /payments/v1/consents e GET /payments/v1/consents

Campo: date

Qual o problema: O campo de data de pagamento no respectivo Schema dos endpoints apontados estão com a descrição "Data do pagamento, conforme especificação RFC-3339.", o que não deixa claro qual o fuso horário a ser adotado

Como deveria ser: Deveria estar definido explicitamente a regra para esse campo de qual o fuso horário deverá ser adotado para o campo

Orientação: Considerar o fuso horário deste campo como Horário de Brasília

Fase 3 – Rejeição do Pix por insuficiência de saldo na conta

Será incluído em 01/11 na planilha de problemas conhecidos Fase 3 o seguinte ponto:

API/Sessão: API Payments / Schema EnumRejectionReasonType

Endpoint: GET /payments/v1/pix/payments/{paymentId}

Campo: rejectionReason

Qual o problema: Atualmente, não há nenhum domínio no EnumRejectionReasonType para reportar que o Pix foi rejeitado por insuficiência de saldo na conta do cliente na detentora quando validado no fluxo assíncrono

Como deveria ser: Deveria ter uma opção no domínio para reportar esse motivo de rejeição

Orientação: Utilizar a opção INSUFFICIENT_FUNDS para este cenário