Consentimento

No compartilhamento de dados cadastrais e transacionais, o "consentimento" denota a autorização concedida por um cliente de uma instituição participante do Open Finance para que outra instituição possa acessar informações sobre os produtos (recursos) detidos pelo cliente. Essa autorização é dada de forma explícita e detalhada.
O cliente, que é o principal interessado no compartilhamento de suas informações, detém o poder de determinar quais produtos a instituição terá acesso. Além disso, dependendo do tipo de produto, ele pode especificar a origem precisa dos dados. Por exemplo, no caso de produtos do tipo "conta", o cliente tem a capacidade de escolher quais contas específicas terão seus dados compartilhados. Para outras categorias de produtos, como operações de crédito, o cliente pode indicar as modalidades de compartilhamento. Isso inclui autorizar a consulta de dados relativos a produtos que estejam atualmente contratados, bem como produtos que possam ser adquiridos no futuro, durante o período de validade do consentimento.

Máquina de Estados

O consentimento é uma entidade que possui estados indicando a sua situação da permissão de compartilhamento de dados do cliente. Existem 3 estados possíveis para um consentimento:

• AWAITING_AUTHORISATION: estado inicial quando um consentimento é criado. Neste estado, o consentimento representa apenas uma intenção de compartilhamento, indicando quem é o cliente que irá realizar o compartilhamento, quais permissões estão sendo solicitadas e a sua data de validade. Neste momento ainda não estão definidos os recursos a serem compartilhados.
• AUTHORISED: estado que indica que o consentimento foi aprovado pelo cliente e que é possível realizar o consumo de dados. Neste estado os recursos ao qual o consentimento dá acesso já foram selecionados, seja através dos seus identificadores ou através da sua modalidade. Apesar do consentimento estar aprovado, ainda poderão existir recursos cujo acesso dependa de uma aprovação de múltipla alçada.
• REJECTED: estado que indica que o consentimento foi revogado. A revogação pode se dar por diferentes motivos, como expiração do tempo máximo para autorização e aprovação do consentimento, vencimento da data de validade do consentimento após a sua aprovação ou ainda uma revogação explicita solicitada pelo cliente.

Regras de transição de estados

• AWAITING_AUTHORISATION pode transicionar para:
  • AUTHORIZED: Quando o consentimento for aprovado através da jornada de autorização, onde os recursos são selecionados;
  • REJECTED: Quando o consentimento não for aprovado dentro de 60 minutos após a sua criação; Quando o cliente rejeitar o consentimento na jornada de autorização.
• AUTHORISED pode transicionar para:
  • REJECTED: Quando o consentimento atingir a sua data de validade;
    Quando o cliente solicitar a revogação no portal de gerenciamento de consentimentos na receptora de dados ou na transmissora de dados;
    Quando a receptora ou transmissora de dados suspeitarem de alguma fraude.
• REJECTED é um estado final e não pode ser alterado.

Controle de acesso a uma API – Escopos e Permissões

Open Finance Brasil adotou o FAPI como o padrão de segurança. Este padrão, fundamentado no modelo OAuth2, emprega o conceito de "escopos" para definir o nível de autorização associado a um token de acesso. De maneira simplificada, depois de concluídos os procedimentos de autenticação e autorização para um consentimento, é gerado um token de acesso. Este token é vinculado a uma lista de escopos que representam a permissão para acessar determinada API e seus endpoints.

No entanto, a utilização dos escopos por si só não proporciona granularidade adequada para um controle preciso das operações, grupo de dados, recursos e modalidade de recursos que foram autorizados a serem compartilhados. Desta forma, estas informações são vinculadas ao consentimento.

Com isso, para o acessar os dados de um recurso é necessário possuir um token associado ao escopo exigido para consumo de uma API/endpoint e um consentimento que de a permissão de acesso a operação e ao recurso desejado.

Regras para a criação do consentimento:

1. A receptora de dados deve enviar as permissões desejadas em grupo mínimo de permissões definidos para cada tipo de produto;

2. A receptora de dados pode solicitar mais de um grupo de permissões ao mesmo tempo, respeitando a intenção do cliente durante a criação do consentimento;

3. Para produtos com seleção por agrupamento de recursos ou agrupamento de produtos, a transmissora deve manter as permissões do agrupamento solicitado,
   mesmo quando não os comercialize;

4. Para produtos que exigem a seleção individual de recurso na aprovação do consentimento, caso a transmissora ofereça o produto (contas e/ou cartões), a transmissora deve retornar as permissions no pedido de criação do consentimento independente se o cliente possui ou não este produto;

5. Se após a remoção de um agrupamento de produtos não restarem permissões funcionais, a transmissora deve rejeitar o pedido de criação do consentimento dando um retorno HTTP Status Code 422, com a mensagem "SEM_PERMISSOES_FUNCIONAIS_RESTANTES";

6. Nas situações abaixo, a transmissora deve rejeitar o pedido de criação de consentimento, dando retorno HTTP Status Code 422 com as mensagens especificadas abaixo:

   a. Caso, no pedido da criação do consentimento, a transmissora valide a ausência de parâmetros PJ e presença de permissions CUSTOMERS BUSINESS deve retornar HTTP Status Code 422 com a mensagem “INFORMACOES_PJ_NAO_INFORMADAS”;
   b. Caso, no pedido da criação do consentimento, a transmissora valide a presença de parâmetros PJ e presença de permissions CUSTOMERS PERSONAL deve retornar HTTP Status Code 422 com a mensagem “PERMISSOES_PJ_INCORRETAS”;
   c. Caso recebam uma solicitação de consentimento com permissões de dados cadastrais PF e PJ em conjunto, retornar HTTP Status Code 422 com a mensagem “PERMISSAO_PF_PJ_EM_CONJUNTO”;
   d. Caso a Instituição Receptora envie permissões divergentes ao agrupamento especificado na tabela abaixo, retornar HTTP Status Code 422 com a mensagem “COMBINACAO_PERMISSOES_INCORRETA”.
   e. Caso a Instituição Receptora envie data de expiração maior que um ano ou uma data referente ao passado, deve-se retornar HTTP Status Code 422.

7. Caso seja identificado um cliente PJ na jornada de criação de consentimento, deve-se exibir apenas marcas que suportem públicos PJ ou ambos (PF e PJ) para escolha. As marcas que contemplam público PJ podem ser selecionadas no diretório nos casos em que a flag de seleção de público está preenchida com a opção “Suporta Contas PJ”​;

8. Caso seja identificado um cliente PF na jornada de criação de consentimento, deve-se exibir apenas marcas que suportem públicos PF ou ambos (PF e PJ) para escolha. As marcas que contemplam público PF podem ser selecionadas no diretório nos casos em que a flag de seleção de público está preenchida com a opção “Suporta Contas PF”.

A tabela abaixo indica, para cada produto, os agrupamentos de permissões válidos e como é realizado a seleção de recursos, por identificador ou por modalidade. Produtos cuja seleção de recurso seja por identificador devem ter o agrupamento de permissões removidos quando a instituição transmissora não oferecer o produto. Já produtos cuja seleção de recurso seja por agrupamento de recurso ou agrupamento de produtos deve ter as permissões mantidas mesmo quando a instituição transmissora não comercializar o produto solicitado.

Cenários de casos de erro

Foram mapeados alguns erros esperados durante o fluxo do usuário no ecossistema. Existem orientações específicas já tratadas no Guia de Experiência do Usuário. Aqui, trataremos a visão mais técnica do que pode ser feito em caso de erro:

• Durante o redirecionamento do Consentimento, não se encontrou o browser no dispositivo do usuário: Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de Consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo Consentimento para tentar novamente a autorização do usuário.
• Durante o redirecionamento do Consentimento, houve um problema inesperado no servidor do Transmissor (HTTP Code 4xx ou 5xx): Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de Consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo Consentimento para tentar novamente a autorização do usuário.
• Durante o redirecionamento do Consentimento, houve um problema inesperado no servidor do Transmissor (Timeout, queda de Internet, etc.): Além da orientação do usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de Consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo Consentimento para tentar novamente a autorização do usuário.
• Durante o redirecionamento do Consentimento, houve um problema com o Login do usuário (erro de credenciais): Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de Consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo Consentimento para tentar novamente a autorização do usuário.
• Após o Consentimento do lado do Receptor, o usuário não finaliza o fluxo de compartilhamento deixando o fluxo pendente. Como a intenção de Consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo Consentimento para tentar novamente a autorização do usuário.
• Após o Consentimento do lado do Receptor, o usuário rejeita o compartilhamento. O consentimento é alterado para o status REJECTED e não pode mais ser utilizado para compartilhamento de dados.
• Após o Consentimento completo, o app do Receptor não consegue acessar os dados por indisponibilidade: Deve-se tentar novamente. Access Token ainda é válido, portanto deve-se tentar novamente sem maiores prejuízos técnicos.
• Após o Consentimento completo, o app do Receptor não consegue acessar os dados por pendência de autorização de um terceiro (ex.: Dupla alçada): Deve-se consultar a API de Recursos (Resources) para verificar as pendências e saber como proceder.

---

Orientações para uso do token de consentimentos: ​

1. O estado e a validação do consentimento devem ser considerados antes do acionamento do token.
2. Após a identificação de que um consentimento está vencido/inativo, é indicado que não haja recorrência de acionamentos do token, que está inválido, para realização de consulta de informações e acesso aos serviços a fim de evitar comportamentos de consumo inadequado das APIs.