Revogação da necessidade de implementação de refresh_tokens opacosRemoção de obrigatoriedade do atributo typ na especificação de segurança do novo perfil único FAPIAdoção da política de versionamento nos documentos de segurançaLançamento da minor (v1.1...

Revogação da necessidade de implementação de refresh_tokens opacos

Considerando que não existe padrão definido em RFC a respeito do formato para uso de refresh_token, informamos que foi realizada alteração do item 24 da seção 5.2.2 do documento do Perfil de Segurança do Open Finance Brasil:

De: “Deve emitir refresh_tokens exclusivamente do tipo opaco e sem prazo de validade associado”;

Para: “Deve emitir refresh_tokens (JWT ou opaco) sem prazo de validade nos cenários onde o mesmo é necessário”.

Note que essa alteração revoga a exclusividade de uso de refresh_tokens opacos no novo perfil, mantendo a possibilidade de utilização de refresh_tokens JWT no ecossistema. Também ressaltamos que não são esperados impactos nos testes de conformidade do novo perfil FAPI único.

Clique aqui para acessar o Perfil de Segurança do Open Finance Brasil

Remoção de obrigatoriedade do atributo typ na especificação de segurança do novo perfil único FAPI

Para adequação da especificação de segurança à RFC, informamos que foi realizada a remoção do trecho “typ - deve ser preenchido com o valor JWT” da seção 6.1 do documento do Perfil de Segurança do Open Finance Brasil. A especificação exigia a presença do atributo typ, entretanto, conforme a seção 4.1.9 da RFC 7515, este atributo é opcional.

Ressaltamos que o ajuste se aplica somente à documentação do novo perfil único (versão 2.0 da documentação de segurança, válida para a implementação do perfil FAPI 1.0) e a remoção desta informação não afeta os cenários de testes já previstos nos motores de conformidade do novo perfil.

Clique aqui para acessar o Perfil de Segurança do Open Finance Brasil

Adoção da política de versionamento nos documentos de segurança

Com intuito de adotar controle de versões e facilitar a rastreabilidade de alterações, informamos que foi adotada uma política de versionamento dos documentos de segurança do Open Finance Brasil.

Dessa forma, esclarecemos que as documentações de versão v2.0 referem-se ao novo perfil único FAPI 1.0, enquanto as versões v1.0 atendem aos perfis atuais.

Clique aqui para acessar a seção de documentos de segurança no portal do desenvolvedor do Open Finance Brasil

Lançamento da minor (v1.1.0) da API Investimentos - Renda Variável

Informamos que a área do desenvolvedor do Portal do Open Finance Brasil foi atualizada no dia 19/12/2023 com a documentação da nova versão estável (v1.1.0) da API Investimentos - Renda Variável.

A nova versão contempla a alteração da restrição do campo transactionQuantity, removendo a obrigatoriedade de preenchimento caso o transactionType seja 'Aluguéis'.

O motor de certificação funcional estará disponível até 15/01/2024 para execução de teste específico do versionamento minor da API.

A execução do teste não será obrigatória

Clique aqui para acessar a v1.1.0 da API Investimentos - Renda Variável

Inclusão de orientação sobre o padrão de contabilização de TPM na área do desenvolvedor

Comunicamos que foi atualizada a página “Limites de tráfego” na área do desenvolvedor no portal do Open Finance Brasil. Para haver uniformidade na aferição dos limites de tráfego e evitar problemas de interoperabilidade, foi incluída a orientação sobre o padrão de contabilização de TPM.

Para maiores detalhes, consultar a página Requisitos não funcionais -> Limites de tráfego.

Clique aqui para acessar a página “Limites de tráfego"

Service Desk – Melhoria no processo de reclassificação dos chamados de incidentes

Informamos que no dia 28/12/2023 será disponibilizada uma melhoria no processo de reclassificação dos chamados de incidentes no Service Desk.

Ao selecionar o status “AGUARDANDO IMPLEMENTAÇÃO N2”, a instituição que informar a data para implementação da correção posterior ao prazo de SLA do chamado poderá solicitar na janela que ficará disponível a alteração do tipo de erro, conforme os critérios da Instrução Normativa BCB Nº359.

Se o chamado não estiver adequado às regras que justificam o pedido de alteração do tipo de erro, a instituição deverá informar o motivo da implementação após o prazo de SLA.

Enfatizamos que os chamados que necessitam da alteração do tipo de erro, e não passarem pelo status “AGUARDANDO IMPLEMENTAÇÃO N2”, devem seguir o fluxo descrito no artigo SLA Dinâmico - Fluxo de Atualização do Prazo de SLA para solicitar a alteração.

Em caso de dúvidas referentes a esta atualização, faça a abertura de um chamado na plataforma do Service Desk.