Workshop Implementação FAPI Único - Go live e período de convivência
Sumário Regulatório
Workshop de implementação do novo Perfil FAPI Único realizado em 18/03/2024 pelo Open Finance Brasil. Nesse workshop foram dadas instruções com relação à entrada em produção do novo Perfil FAPI Único e como se dará o período de convivência com outros perfis. As informações deste vídeo se referem ao momento em que esse foi realizado (18/03/2024) e está passível de alteração ao longo do tempo. Portanto, é sempre recomendado consultar as informações atualizadas nos portais oficiais do Open Finance Brasil. Links úteis: ►Pagina de calendários - Calendário com as datas de lançamento de especificações, de atualização do motor de conformidade, go live, entre outros: https://openfinancebrasil.atlassian.net/wiki/spaces/OF/calendars ►Informas - Consolidado dos comunicados enviados ao ecossistema: https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/17367115/Reposit+rio+de+Informes ►OpenID - Responsável pela certificação e pelos testes de segurança: https://openid.net/ ►Motor de Conformidade de Segurança: https://www.certification.openid.net/login.html ►Gitlab OpenID - Para abertura de tickets sobre dúvidas e/ou problemas no motor - Recomendamos a abertura de tickets através do Gitlab, pois ela permite o acompanhamento e interação com dúvidas de outras instituições e dá visibilidade para itens que já estão em correção ou que já foram esclarecidos: https://gitlab.com/openid/conformance-suite/-/issues/?sort=created_date&state=opened ►Service Desk - Canal para envio de dúvidas das instituições e envio de notificações pela Estrutura: https://servicedesk.openfinancebrasil.org.br/Login.jsp?navLanguage=pt-BR
Transcrição e Conteúdo
acho que a gente pode Começando aqui então primeiro eh Boa tarde a todos Obrigada pela presença de vocês a ideia é que a gente já tem feito uma tentado investir mais aqui nessa série de reuniões e workshops para tentar aproximar melhorar a comunicação aqui da estrutura com o lado das instituições Então esse daqui é mais uma dessas iniciativas então o objetivo desse dessa reuniã...
então primeiro
eh Boa tarde a todos Obrigada pela
presença de vocês a ideia é que a gente
já tem feito uma tentado investir mais
aqui nessa série de reuniões e workshops
para tentar aproximar melhorar a
comunicação aqui da estrutura com o lado
das instituições Então esse daqui é mais
uma dessas iniciativas então o objetivo
desse dessa reunião de hoje a gente
entrar um pouco no detalhe A gente vai
ter na semana que vem a o go Live do
novo perfil fap único de segurança e a
gente vai ter um período de convivência
então a ideia a gente passar aqui um
pouco pelos detalhes de como que vai ser
essa entrada em produção eh como que vai
ser eh esse período de convivência
algumas orientações para as instituições
algumas recomendações então passar aqui
por esse por esse processo e esse
workshop ele vai ser gravado e a gente
vai compartilhar o link da gravação
depois no canal do you YouTube e as
dúvidas a gente vai tratando por ordem
das mãozinhas eh ou podem ir mandando no
chat que a gente vai tentando responder
aqui pela própria mensagem ou qualquer
coisa depois a gente vai a gente
responde aqui na Fala também o que não
dá para responder direto pelo chat tá eh
então agradecer de novo a todos
especialmente aqui o Paulo agora passo a
palavra para você então o nosso
especialista aqui que vai comandar a
apresentação Bom dia pessoal fav se você
quiser passar o slide do cronograma isso
só para lembrar a etapa que estamos né A
gente tá chegando no no final do período
de emissão de certificações ali
ã e no dia 25/03 acontece o go Live do
novo perfil n o perfil únic F ali
teríamos duas semanas paraos
participantes fazerem o processo de dcm
nesse período existe uma convivência das
duas versões Então nada deveria quebrar
né Eh tudo continua funcionando da forma
que as casas têm duas semanas aí para se
ajustar pro novo perfil né fazer os dcms
as mudanças e no dia 14/04
ã Todo mundo precisa estar no perfil
novo e será desligado o perfil antig os
perfis antig né a ideia que hoje a gente
falar um pouco desse período de de
migração né de mudança
ã algumas características as principais
características estão que estão mudando
e como isso afeta Tecnicamente eh as
nossas url de aom o comportamento das
casas eh para Que asos participantes
consigam se planejar pro período de
convivência né e e e e e e fazer esse
processo com mínimo de impacto possível
desejando ter Impacto zero para todos os
participantes aqui ah acho que vale
lembrar que tem uma instrução normativa
não vou lembrar o nome agora de cabeça o
número de cabeça que que Versa sobre
esse período de convivência sobre o
período de DCR dcm os principais
participantes alios participantes que
mais T consentimentos Ah tem Marcos a
serem seguidos durante esses duas
semanas né então 10% de dcm efetivado
até tal data 30% em outra data tem
Marcos estabelecidos que precisam ser
observados com intuito de garantir né
que a gente chegue no no novo perfil sem
quebrar o ecossistema né sem quebrar
essa
comunicação eh bom eu não Montei um Deck
de material Na verdade o que a gente vai
faz o que eu vou fazer é apresentar a
própria página do portal que a gente
montou
ã para falar desses aspectos técnicos
existentes tá então esse material vai
estar no portal ele vai ser colocado ali
eh eh ou ou na parte de segurança não
ten certeza ou vai ficar com ali junto
com diretrizes técnicas operacionais não
sei F se como ficou combinado no final
das contas mas a gente vai pôr um dos
dois e e coloca num comunicado dizendo
que está disponível material né e aqui a
ideia desse material é falar sobre os
aspectos técnicos no final tem um fac e
a ideia é que conforme forem chegando
dúvidas ou forem aparecendo questões
relevantes a gente enriqueça essa sessão
de fac para todo mundo ter acesso às
informações minimizando possíveis riscos
aqui do processo tá
então material ele começa com contexto e
de forma geral Resumindo o que a gente
quer é
processo um
[Risadas]
áudio durante o processo de convivência
os processos de DCR dcm funcionem da
forma adequada né então eu consigo ir
pra frente pro perfil fap único sem
problemas mas se eu tiver um problema eu
consigo fazer o né e continuar tratando
funcionando operando Até resolver o é
conseguir fazer o novo processo de dcm
para validar minha minha solução e da
mesma forma né os meus processos fis né
o meu geração de consentimento aprovação
de consentimento deve continuar
funcionando ã no no no no no perfil novo
né no perfil único eu consigo gerar
novos consentimentos novos tokens usando
perfil novo mas toda a minha base de
tokens existentes os meus acess token
fres tokens continuem funcionando no
período de convivência até eu fazer a
migração sem nen um impacto pro cliente
né tem que ser transparente p ponto de
vista do cliente né esse processo não
deveria gerar nenhum Impacto né
Ahã aqui entrando um pouco no cronograma
né até o dia
24/03 todo mundo tem que ter a
certificação de ril pares a iniciadora
né Precisa ter certificação de ril em
pares eh da IDF né aí as detentoras e
transmissoras precisam ter as
certificações de DCR dcm ã
eap né E até o dia 24/03 final do dia
23:59 publicar esses links de
certificação e fazer a sua mudança né
colocando no ar o novo perfil né
atualizando o RL atualizando todos os
links de certificação e garantindo que
ele já esteja disponível para quem
queira fazer o processo de DC então
datar muro
24/3 235 9 todo mundo tem que estar
habilitado pro novo perfil né a partir
do dia 25 0 horas né entre o dia 25 e
dia 14 ã os iniciadores e receptores
fazem o processo dcm DCR que que for ali
fato ã para mudar todos os seus clientes
pro perfil novo e as detentoras T que e
transmissoras ficar atentos Aos aos SAS
que foram colocados na na in 44 TRS ali
referente a tickets né Acho que se não
me engano são 2 horas me0 para atender
tickets ah referentes ao processo de
migração né que que ocorre ã após dia 15
do4 acaba convivência todo mundo tem que
ter feito o processo de dcm né e as
detentoras desligam Oix parte perfil
antigo desculpa eu vi uma mão subindo
não estou vendo os nomes se se alguém
consegue me ajudar família
Fernando pode falar só para ficar claro
durante o período de transição eu
continuo suportando dcm DC dcm no perfil
antigo uma iniciadora que nunca
cadastrou ela pode fazer no perfil
antigo com a gente durante o período de
transmissão sim pode tá é um ponto que a
gente questionou g de segurança não faz
tanto sentido né pô já já tem que fazer
para em uma duas semanas já ter que
mudar né mas Ah para simplificar e e e
garantir que não vai haver impacto nos
processos de rack de alguma de alguma
iniciadora ou receptora de dados sim é
possível fazer o processo de DCR durante
o período de convivência é óbvio que não
deveria acontecer deveria ficar focado
no dcm
ali Rodrigo eh Boa tarde pessoal sou
aqui do Santander e coligadas tá só uma
dúvida em relação a esse cronograma a
gente recebeu um comunicado ah com
possível calendário para iniciar tipo um
um morum alguma coisa assim eh no dia 24
então Tecnicamente não seria dia 25 o
início né teria que ser antes né a gente
teria que tá preparado para começar no
dia 24 não é
isso Rodrigo sobre esse ponto você quer
falar Paul que pux não não pode falar
justamente para você puxar tranquilo eh
a tem uma uma lista de instituições da
in 443 que precisa tem algumas
obrigações adicionais ali em relação a
esse período de dcm tem que eh cumprir
uma porcentagem de dcms até alguma
algumas datas específicas então a gente
tá tentando organizar esse War room e a
gente acabou sugerindo dia 24 para
entender que final de semana costuma ter
um volume menor de de chamadas Então se
as instituições da in 443 preferissem a
aí a gente teria organizaria no domingo
e aí teria que realmente adiantar ali
para eh um pouco esse go Live mas é
focado nessas instituições tá a gente
recebeu até agora meio-dia as respostas
tinha instituição que tava faltando a
gente vai fechar o resultado mas eu tô
imaginando que vai acabar ficando na
segunda-feira mesmo tá mas aí a gente
vai entrar em contato com vocês e também
D essas orientações específicas para
para esses próximos passos tá entendi
formulário era só para para ver qual que
seria a melhor data para todo mundo né a
criar warun por exemplo dia 24 dia 25
dia 26 etc né não a ideia é ser um
período de 4 horas para todo mundo
dessas instituições da in 443 estarem na
mesma sala então do Santander tem um
problema com o Bradesco por exemplo
vocês já conseguem como tem ess sla
muito curto vocês já conseguem se
resolver então seria um período pros
técnicos estarem online eh para já
conseguir resolver qualquer problema ali
de imediato Ah legal porque tem 10% né
até o dia 26 né uma coisa assim tem os
Marcos que citou né então ficaria meio
apertado mesmo né Se tiver algum
problema mais complexo né entendi Não
sem problema até quando ação é essa
então vai ser um dos horários só tá Oi
desculpa Rodrigo até quando que ficou de
fechar isso
ah a gente acabou de receber todas as
respostas a gente só precisa consolidar
para ver qual vai ser o melhor horário
Tá mas acho que até amanhã na hora do
almoço a gente manda para vocês como que
ficou Ah
beleza obrigado gente
imagina b então vendo se tem mais
Guilherme acho que é para
cilme para mim apareceu que abaixou a
mãozinha
seguindo qualquer coisa à
vontade bom principais mudanças no
perfil Fabi aqui as mudanças que trazem
algum Impacto técnico
tá adoção no perfil único para ver n a
gente trouxe esses detalhamentos de
mudança no workshop anterior Tá
disponível no no
sharepoint tem um link também que foi
disponibilizado no no YouTube né a gente
pode compartilhar mas o detalhamento do
que é cada essa mudanças existe no
workshop e aqui eu vou falar de como é o
período de convivência para cada um
desses aspectos tá então ã adoração de
perfil único Private k mais par né e
aqui a gente tá falando de método de
autenticação e uso do par tá são dois
assuntos numa linha aqui ã criptografia
do id token né então antes ele era
opcional só só na verdade você só
precisava usar o ID token se fosse
trafegar alguma informação pii no seu ID
token se você não tivesse você não
precisava fotografar e agora ele passa a
ser obrigatório em todos os casos né ah
o pkce se torna obrigatório quem usa par
já usa pkce tá o par já já exige o uso
do pkce mas como tinha instituições que
não usav par ã ele passa a ser
obrigatório para todo mundo né ah Clin
CPF CNPJ l de tokens São removidas Ah
existe uma proibição da rotação do
registration acess no processo de DCR e
dcm né para evitar problemas de perda de
chave
ã e necessidade de ficar fazendo
tratativas bilaterais para se recuperar
Então se bloqueou essa rotaciono
ah algumas restrições dos parâmetros
response Type response mode e subject
type são as principais mudanças aqui que
impactam de alguma forma o nosso período
de convivência tá
Ah primeiro falando aqui do do perfil
único né como método de autenticação o
fap prevê dois métodos de autenticação o
Private Key e o mtls né E eles podem ser
combinados com o uso do par ou não né
com par ou sem par e com uso de jarme ou
sem uso de jarme né fazendo toda a
combinação da oito perfis que tinha
disponíveis no nosso faf BR 1.0
anteriormente né com fap único a gente
falou não não queremos oito perfis
queremos um único perfil vai ser para VQ
com uso de p né e sem uso de jar né ã
então aqui é o primeiro grande Impacto
né e a principal mudança que a gente tá
tendo né então todo mundo vai ter que
passar prover esse novo perfil para ver
que jwt e quem anteriormente utilizava o
mtls vai ter que manter a convivência
pro mtls ã durante o período de
convivência para depois desligar tá como
que isso reflete na nossa URL de wn nos
nossos dados de wn e registros dos
nossos clientes né
Ah bom o o Private Key e o mtls eles
eram suportados no fap ber 1.0 você
poderia escolher qual dos dois você
queria obviamente Obviamente você
precisava ter um deles né mas você
precisava eh poderia ter um ou mais um
ou mais né Poderia ter os dois ou um só
ã com o fap único se torna obrigatório
que seja o prq e o mtls deixe de de ser
suportado tá então
ã antes eu suportava os dois escolhia
qual que eu ia ter agora eu sou obrigado
a ter o para ver que jwt e não posso ter
o mtls
Ahã isso é contado na nossa wn né nossa
na nossa de de Relembrando para todo
mundo é um um endp em que os clientes
Podem bater do authorization server para
pegar as configurações que aquele
autoriz server aceito né como que eu
trabalho o que que eu aceito como
algoritmos de criptografia qu Quais são
as minhas ur de autenticação quais são
minhas urls de revogação de token né Eh
então o ele traz todo o a instrução de
como você pode utilizar aquele
autorisation server né ã e a mudança do
perfil faz com que essas instruções
precisem ser atualizadas e aqui a gente
tá contando um pouco como que deveria
ser feita essa atualização então a
principal parâmetro aqui não é o n é o
token al meod supported é uma lista né
de métodos que pode receber o valor priv
jwt ou tls client Alf representando PRS
respectivamente né Essa lista antes
poderia ter um ou mais membros agora só
vai poder ter um e o período de
convivência que a gente vai discutir
aqui tá existem outros parâmetros que
também trazem essa informação para
outros fins mas que não é obrigatório
estar
no na URL de mas alguns participantes
fazem isso porque
ã a informação está disponível em algum
em algum Point distinto né Por exemplo
Ah eu tenho aqui o rogation point of
method support então para revogar um
token acesso eu aceito esses canais aqui
ã para fazer introspecção do meu token
né eu suporto esses esses métodos aqui
né então ã nem todos os participantes
declaram isso e não declarar significa o
uso básico do do do CL credential se eu
não me engano né
Ahã mas para quem declara precisa seguir
as regras que vão estar definidas dentro
do política do fap Tá mas o foco aqui fo
que a gente põ off metod de suport tá e
alguns cenários podem ocorrer n Eu tenho
um cenário em que na minha implementação
do fap 1.0 eh ã eu suportava apenas um
dos métodos né ã e eu vou ser obrigado a
mudar para outro método ou ficar ou ou
manter o mesmo método dependendo de como
estava né então se eu era mtls n
primeiro exemplo Vocês conseguem ver meu
mouse
desculpa conseguimos sim paa então se
você era mtls você durante o período de
convivência precisa deixar os dois
disponíveis né então novas instituições
que já migraram fizerem o dcm né tem que
est disponível no formato e quem ainda
não fez o dcm precisa ser suportado
manté né após a término de convivência
eu desligo mtls mantenho só o prev k né
quem é preved k nem não existe nenhum
token no formato mls nemum consentimento
que usa mls Então pode manter o Private
ke durante todo esse período sem Impacto
né para quem já suportava ambos os
cenários né quem suportava mais de um
perfil durante o período de convivência
precisa manter os mesmos perfis então
precisa manter os mesmos métodos de
acesso após o período de convivência
desliga mtls e manté de Só preved K tá
então primeiro Impacto aqui devido aos
métodos
ã de autentificação acho que alguém
levantou a mão não sei se
continua para mim não tá aparecendo Paul
tá levantar é para é para mim apareceu e
sumiu então não sei se mas seguinte né
ainda em relação ao perfil único né ã o
uso do par né então é parv que jwt mas
com o uso de para obrigatório fo isso
que foi decidido né e em consonância ali
com o caminho do fap 2.0 né ã o fap 2.0
ele ele vai na linha de zer PR k né
ã e e e uso do par né então a gente
sonância tá indo P mesmo caminho né ah e
isso afeta todos os participantes né
durante o período de convivência eu
tenho que garantir que quem não usava
par os clientes que ainda não usavam par
né que estavam registrado sem uso de par
continuem funcionando então tenho que
suportar opção sem par
e novos tokens que usem par de clientes
que já fizeram o o dcm funcionem usando
par e após termino de convivência eu
mantenho apenas uso de par né então de
novo no R não existem variáveis que
falam sobre uso do par basicamente são
duas variáveis
né eu tenho oor
requ end Point que é o end Point que
você faz a o uso do par propriamente
dito né você avisa das variáveis para
aquela autenticação e e pega o seu
código e existe um segundo parâmetro que
é um boleano que fala se o
o o uso do para é obrigatório ou não né
então no fap BR 1.0 uso do para era
opcional né E você poderia ter Olha eu
aceito o par mas ele é opcional eu
Aceito o par e ele é obrigatório né ã E
isso tem que vai para um perfil único né
então é obrigatório uso do par e você
precisa ter o end Point preenchido Hum e
a variável obrigatoriedade do par vai
ter que ser Obrigatoriamente valor true
porque você agora exige que tenha par
sempre uso do P né Então como que fica
nos cenários dos participantes das
implementações né alguns participantes
não declaravam as variáveis do par
porque elas não faziam uso
durante o período de convivência Elas
têm que habilitar o uso do par mas
manter ele ainda como opcional porque eu
vou ter os clientes que ainda não
fizeram a migração pro perfil novo sem e
ainda não vão saber usar o par durante
aquelas duas semanas e ao término das
duas semanas eu
ã torno obrigatório o uso do par né
ã para quem já usava par e e era
opcional ele mantém durante Pero de
convivência opcional
ao término torna obrigatório e para quem
já usava o para Obrigatoriamente nada
não tem impactos fica tudo do jeito que
está
ã pkc né o pkc é um um método de
segurança para aumentar a probabilidade
eh a mitigação de de ataques emid ou ali
interceptando as chaves que estão
trafegando os códigos né então são
gerados os códigos com desafios e e
Chaves ali para garantir Ah que quem fez
a a primeira requisição é quem está
fazendo a próxima requisição e isso com
o uso do par se torna obrigatório né
ã aqui não tem impacto na URL de Não
isso não é um uma característica não é
RL de não mas é um comportamento que os
participantes vão ter que adotar né
então
ah participantes que não suportavam par
e e e não faziam uso do pkce precisam
começar a suportar o pkce mas precisam
manter os clientes que não fazem uso
pkce o uso né e eh sem sem eh
autenticação sem uso do pkc né de manter
convivência e para quem já tinha o p ou
para quem já tinha o PCC
consequentemente ali né Sem impactos
então aqui o ponto de atenção do Pr
período de convivência é que você
precisa manter o suporte ah a a
autenticações sem pkc durante o período
de convivência né
ã criptografia do id token né
ah aí como eu expliquei um pouco antes
ele era uma característica opcional né
você só precisava encriptar o encriptar
o ID token se ele fosse trafegar alguma
informação sensível
na isso gerava uma certa variação né a
hora vinha encriptado hora novinha
dependia de como fazia a solicitação se
pedia CPF PJ ou dos dados que casa que
que o transmissor ali tava colocando
dentro do editor né para eliminar essa
variação a gente tornou obrigatório a
incitação né
ã e isso ele reflete ã no Ed token no
desculpa Na ROM
Ahã Pois é necessário indicar Quais são
os Ed tokens suportados a lista de a
lista de algoritmos Ed tokens suportados
né são duas variáveis aed token ction AL
suort e a de token caption ent V support
Ah mas como
anteriormente isso já era utilizado em
algumas cenários provavelmente todos os
clientes já têm essas variáveis ou todos
os servidores já TM essas variáveis
preenchidas né então pacto provavelmente
é baixo aqui a única questão é uma
questão de comportamento que os
receptores podem sofrer se você antes
não encriptou editou quem passou a
encriptar Pode ser que quebre um client
que não esteja preparado para isso né
então você precisa avaliar se aquele
cliente está preparado ou não né ou ele
foi registrado para o uso de ID token
criptografado se sim ou que criptografar
se não ã pode gerar uma quebra aqui
então ponto de atenção
ah CL CPF CNPJ elas deixam de ser
suportadas no novo perfil
né
ã devendo ser ignoradas então não é o
não quando a gente fala das clientes
suportadas vinha o CPF CNPJ antes isso
se mantém no período de convivência
depois eu paro de suportar e a partir
desse momento eu ignoro essas clies né e
os clientes precisam se adaptar vão
adaptar seus fluxos de consumo se fazem
uso dessa informação eles vão ter que
verificar outra forma de de resolver o
problema o motivador para eles fazerem
esse uso né
ah rotação do registration assess Token
Ah ela uma mudança que não tem Impacto
pro pra operação né dos tokens ali do da
geração de consentimentos geração deess
token fres token é uma mudança que tem
Impacto apenas pro processo de DCR dcm
que atualmente né é permitida ess essa
rotação e quando você por exemplo faz
uma modificação modifiquei o scopo que o
meu cente Ah tem
n esse token poderia rotacionar e se
você não tivesse sua lógica implementada
para pegar esse rotaciono você poderia
perder o
acesso ao registro ali para fazer
mudanças no seu Cent né Em algumas
situações você poderia tentar fazer uma
mudança e por algum erro técnico não
receber a resposta e perder o acesso né
então para evitar essas situações e
essas tratativas bilaterais se proib o a
rotaciono do
registration né
atributo response
Type o atributo response Type ele diz
ele fala muito sobre como o fluxo de
autorização vai funcionar
n atualmente era Aceito o fluxo code ID
token né que significa que olha após um
processo de de login que eu vou receber
tanto o código de autorização quanto ID
token ou vou receber só o
código e o response mode ali JW resp ter
com um jarme ali né para receber esses
dados né E se eu precisar de alguma
questão de introspecção do tokem eu vou
fazer por outros caminhos né
Ahã no novo modelo passa a ser exportado
apenas o c Ed de token né a gente
derruba a opção de usar Code com jarmo
Ahã E isso tem Impacto Opa Paul tem tem
duas pessoas com a mão levantada só pra
gente não acho que passar
o ponto desses aí clo vocês quiserem por
favor Opa eh Fernando de novo voltando
lá só na parte da encryption Toing eh a
gente não não tem uma previsão de
obrigatoriedade do client no momento do
DCR ele informar a chave isso é
capturado pela indo no no no diretório
pegando qual é a chave do c do do
cliente e isso mas isso não tem todas as
situações que isso era obrigatório ISS
por exemplo AC você só só pagamento isso
não tinha dados em que isso fosse
obrigatório E se o cliente não tivesse
registrado para fazer o
o token
ele se ele pedi se para fazer a
criptografia se ele pedir depois ele não
vai conseguir Então nesse período de
transição se ele não se ele não
registrou ele não tinha o BR O
bro quer qual que é o selo que tem o
acho que é o um enk lá de assinatura né
Isso se ele não tinha o brn configurado
ele não ele não mandou E isso também não
tava especificado que era obrigatório
registrar ele quando ele quando ele
tivesse se ele pedir o Ed token
criptografado ele vai falhar sim sim vai
teros um problema e aí o que que
acontece eh o que que eu faço um depois
e durante o período de transição durante
o período de transmissão transição eu
vou poder não eh mandar sem criptografia
mas depois e o cara não se registrou
para isso eu vou dar eu vou dar bomba
sim tá ele vai ter que fazer um dcm
atualizando o registro dele registrando
agora que ele tenha as chaves de
criptografia necessárias né então ele
sim precisa fazer o cliente precisa
rodar Obrigatoriamente o dcm tá se após
o período de convivência ele não fez
essa execução do dcm
ahã é um problema do cliente que ele vai
ter que resolver né então ele vai
começar a falhar quando você desligar ou
quando você ligar o o a criptografia
obrigatória ali né você não vai ter como
criptografar para esse cliente né então
Eh então eu vou poder operar durante o
período de convivência eu vou operar sem
obrigatoriedade Então ele pode conseguir
tudo tranquilo eh então ele só nesse aí
se ele não se chegar se ele pedir o a
criptografado e ele não fez oer é
problema dele e se depois eu obrigar ele
não pedir e ele não mandou também o
problema dele tá exato vai ver uma Disc
lateral que vai ter que ser resolvido n
Então olha tá falhando provavelmente vai
chegar olha não estou conseguindo criar
tokens com vocês alguma coisa você vai
falar não mas eu tô vendo que você não
tem a sua chave de criptografia
registrada aqui você precisa fazer um
dcm né então ele ele vai ele tem que
fazer o processo de dcm então aqui a
responsabilidade de atualizar o seu
cliente é do receptor do do iniciador de
pagamento né você como transmissor
detentor de conta você tem que habilitar
H que que essa atualização é possível né
e garantir que durante o período de
convivência antes dele fazer qualquer
dcm continue tudo funcionar né após o
período de convivência é esperado que
cara Olha vou desligar comportamentos
antigos isso aqui sem aed tokem deixou
de ser suportada então suas requisições
sem aed tokem vão falhar né e é problema
de você você tem que vir aqui fazer um
DC E aí uma última eh o motor de
certificação ele considerou Qual o
cenário o cenário que só tinha o fap
único e ele verificava verificava as
coisas que já deveriam ter removidas ou
ele vi quee ficou um período de
transição ou ele não não está claro a
situação que o motor de conformidades
verif aqui o motor de conformidade tá
falando do funcional ou de
segurança de segurança FAB segurança tá
eh el eles não foram criadas travas para
validar e você não suporta o anterior
você me corrige tá Fabi mas na
configuração do teste foi criada tr Olha
você vai ter que fazer o teste usando
Private k com par né Ahã e e a intenção
de não botar trava foi justamente
possibilitar que as casas não tivessem
um anom de convivência ali né vai ter
que ser pensado em um momento testes
para garantir que o perfil antigo já não
é mais suportado Mas eles hoje ainda não
não estão feitos tá e a maioria desses
testes envolvem a verificação da
configuração do é
não se eu puder complementar isso daqui
a gente tá planejando alguns testes Ali
pela própria fvp tá então a gente tá
configurando a fvp para a partir do dia
25 validar se as instituições estão
aceitando as configurações ali do novo
perfil
eh e aí em paralelo a gente também tá
planejando alguns testes para a partir
do dia 15 de abril a gente vê se as
instituições já estão rejeitando DCR
dcms com mtls por exemplo tá então com
os perfis antigos então a gente tá
terminando de desenhar esses cenários
para fazer as validações
então a gente só vai ter verdade um
teste para verificar se a eh
anteriormente se se só se quebrou mas
pra gente fazer um uma verificação real
se contra as configurações mesmo num
ambiente desenvolvimento a gente não vai
ter o motor antes dos momentos de
falha correto
correto o motor ele é mais flexível né
nesse aspecto
mas por exemplo acho que a cobrança deid
token já era feita né o motor já cobrava
e o editou quem tivesse criptografado
ele fazia validações né então é uma
linha T né quanto eu consigo
ã garantir a convivência enquanto testar
né o o token o motor já cobrava a
obrigatoriedade da token então ele assim
ele não não consideraria para um período
de convivência o resultado
do mais alguém pessoal eu tinha uma
dúvida Ô o não tinha ficado Claro para
mim o com relação à questão da rotação
do registration Access token se a gente
teria que manter um período de
convivência né Ou seja a gente vai subir
esse cara e independente do o quero ter
feito dcm ou não o ninguém vai me cobrar
né que o regist access tokem eh
eh Deixe de ser rotacionado né do tipo
esse cara aí ele não vai ter um período
de convivência né ele vai deixar de ser
rotacionado e mesmo que o cara volte ele
vai continuar não sendo rotacionado
correto correto acho que aqui o impacto
é mínimo né Porque sim você deixar de
rotacionar você não quebra nada né só a
chave que parou de mudar e e quem tava
prevendo comportament ento de ronar vai
est se recebendo a mesma chave não vai
quebrar então aqui de fato não não tem
problema nenhum Tá show de bola era era
só para confirmar isso tá obrigado tá eh
eu tenho uma dúvida eh no nosso caso a
gente tentou fazer a disponibilização do
mtls compar né atualmente o Mercado Pago
só tem
eh a gente tentou liberar o Private Key
mais o par atualmente a gente só tem o
mtls E aí a gente percebeu que Algumas
casas começaram a dar erro eh quando
estavam tentando gerar o token E aí a
gente teve que fazer rollback como que
tá planejado isso em teoria pelo menos
na minha opinião dia 25 a gente vai ou
sim ou sim liberar com mtls certo para
manter a convivência e as casas que
começarem a falhar que deveriam que se
adequar correto é é que não deveria
haver falhas né deveria ser um processo
transparente
né imaginamos é quando você por exemplo
Estou adicionando um novo perfil e
Private ke eu tinha o mtls né e vou
adicionar o Private ke no perfil novo tá
e é uma nova opção que eu tô pondo na
mesa mas o meu Private o meu mtls que eu
tinha antes e que os clientes estão
registrados ainda está disponível e é
transparente para eles então meu
servidor de autorização vai receber as o
fluxo de chamadas ali no formato da mtls
vai fazer a validação do certificado do
sub da forma que mtls fazia sempre fez
né antes o novo perfil né A partir do
momento que esse client né ele vai ter J
análise duas semanas fizer um dcm
falando OK agora eu vou usar priv fica
um par né
Eh você tem que começar a fazer
funcionar aquele cliente com um novo
perfil né então mtls para de funcionar
com esse perfil ou com aquele cliente
passa a funcionar com o novo com novo
perfil e todos aqueles tokens que ele
tinha
consentimentos continuam funcionando sem
problema né de forma transparente não
deveria ser fiz mudança começou a
estourar um monte de problema agora cam
e ajustem né não tem que ser ao
justamente contrário né eu fiz a mudança
não impactou ninguém e façam o seu DCR
dcm na janela de Convivência de duas
semanas algum alguns participantes TM
uma régua mais rígida que tem Marcos ali
para atingir outros vão poder fazer com
um pouco mais de calma mas é para ser
transparente sem quet
então não sei qual que é o cenário que
exato que conteceu mas vocês
disponibilizarem o novo perfil não
deveria ter gerado
quedra mesmo porque não deveria ter
afetado outros clientes né se eles não
fizeram o dcm só afeta Quem fez o dcm
isso pelo que a gente percebeu tinha
Algumas casas que começaram a tentar
fazer eh usando Private Key sendo que o
o como a gente não tinha né Então eles
deveriam ter seguido pelo mtls né normal
a gente achou bem estranho inclusive até
abrir o chamado mas não não obtivemos
resposta né
eu acho que a gente até respondeu Esse
chamado tá
eh Desculpa cortar Paulo mas acho que eu
voltei aqui agora mas acho que a gente
respondeu Esse chamado de fato é mais um
problema do receptor do que
do transmissor ali tá sim não eu digo
quem não respondeu foi as outras casas
né porque a gente sabia quem era as
casas a gente abriu para elas ninguém se
pronunciou você estava tranquilo eu não
sei quais foram os cenários que
aconteceram com os participantes mas
talvez alguma lógica h de preferência de
perfil que esteja mal configurada e a se
tá disponível ali no é não eu vou usar
mas sem invalidar como registro foi
feito anteriormente né então talvez
tenha alguns ajustes que essas clientes
precisam realizar Tá mas daí é é erro
esse tipo de erro tipicamente é do
receptor não deveria acontecer mas de
fato pode acontecer e acontecer no se no
seu caso
né tá obrigado
pessoal tiver por favor para fazer
pergunta senão sigo aqui com
respons aqui tem mais uma Paulo
doit forçando aqui o ponto pelo que eu
tô acompanhando do do workshop se eu sou
uma
transmissora no dia 24 eu já tenho que
tá ativado tanto o perfil único quanto
mtls se eu sou uma receptora eu eu não
tenho a pressa do dia 24 25 eu posso
fazer por exemplo essa virada no dia 26
pelo que eu tô entendendo mas a
transmissora já tem que tá pronto e que
eu fiquei na dúvida daquela questão da
2359 é se eu tenho um horário específico
para ativar uma vez que vai ter um
período de convivência no sábado do dia
23 eu já posso deixar isso habilitado
até para eu planejar aqui as
implantações
você me corrige tá e o grande problema
de antecipar esse go Live é que
situações não previstas acontecem né
então que nem falaram olha registrei um
novo perfil
e clientes que não eram para quebrar
porque não tem nada a ver Eles não
vieram fazer C começaram a quebrar né E
se eu começo a antecipar isso pode ser
que ess as instituições que são clientes
não tenham alguém de plantão ou est
prevendo esse go Live né então o go Live
deveria acontecer no dia 4 né você
deveria pôr o periodo no perfil no dia
24 e ele tem que ser pode ser qualquer
horário desde que seja feito dentro do
dia 24 porque daí os participantes já
sabem que vão acontecer naquele período
uma mudança ã e a partir daí de fato
manté a convivência e tem a janela de
duas semanas que daí sim o os clientes
vão escolher qual que é o melhor dia
melhor data para eles fazerem o dcm né
exceto os clientes que estão dentro ali
da in 443 que ten algumas metas a serem
atingidas ali a acho que um ponto que é
importante aqui é separar o papel tanto
do iniciador e do receptor versus
transmissor e detentor tá então vou usar
aqui pagamentos como exemplo mas vale
para dados do cliente também aqui o os
os detentores até podem ajustar ali o
seu Elom a configuração no dia 24 que
nem o exemplo que você deu no dia 23 o
ideal é não ser com tanta antecedência
assim mas já pode ajustar mas as
iniciadoras só podem fazer o dcm a
partir do dia 25 então a não tirando a
exceção ali caso a gente acabe marcando
War room no domingo a ideia é realmente
que
o que as detentoras e transmissoras
estejam Preparadas para no dia 25 as
iniciadoras e receptoras poderem acionar
Mas não é para esse acionamento paraa
mudança do perfil acontecer dia 20 por
exemplo tá aí Paulo me corrije aqui
qualquer coisa sei
desculpa gente mas o o já tem essa
definição da data então que vai ser no
dia 23 ou no dia 24 porque o que eu fiz
aqui foi responder um
forme não não o esse War room a gente tá
fechando a data vai ser domingo segunda
ou terça tá
aí a única exceção para fazer o dcm no
domingo seria caso o room seja marcado
no domingo domingo tá senão tá mas por
enquanto a gente ainda não tem então uma
data né exato a gente vai mandar para
vocês da instituição da da in 443 até
amanhã na hora do almoço que horas que
vai ser Ah tá entendi perfeito Então tá
mas senão iniciadoras e receptoras
iniciam o dcm a partir do dia 25
pessoal seguindo passar nos outros os
outros são out mamente fáceis aqui então
Eh eu estava falando do response Type né
pode ser code de token ou code no fap no
fap BR 1.0 e no fap único a gente tá
restringindo a cod de token isso afeta
um pouco o fluxo de como as as chamadas
acontecem durante o processo de de
autenticação e geração do acesso t tá
Ah e e e e dessa forma né Eu acho pouco
provável que alguém esteja usando cod
com jarm no ecossistema acho que tem
pouquíssimas instruções certificadas com
jar Tá mas caso tenha alguma institução
que esteja utilizando esse esse modelo
né algum cliente que utiliza esse modelo
ele precisa ajustar seu fluxo de
autenticação para começar a trabalhar no
modelo cled tá
e bom como que isso o RL de não né então
para quem suportava os dois perfis code
de token e Code né durante o período de
convivência Tem que manter os dois né e
após de convivência mantém sua clode Ed
Token para quem suportava apenas um
perfil né o próprio clode Ed token
mantém ele sem sem nenhum Impacto Tá
eh o response mode ele serve para você
dizer como a resposta vai ser trafegado
ali né o durante o fluxo de de
autenticação tá então pode ser através
de qu parameters de fragments
de jwt então tem várias formas que é
combinado né como vai ser trafegado os
dados da resposta com o código de
autorização ali né antes isso estava Liv
né pod ser usado qualquer um query
fragment form post eh jwt vários os que
tivessem definidos ali na nas rfcs né ã
e algumas rfcs aqui tá
[Música]
Ahã por exemplo isso er era o uso do
jarme Ali quando eu tinha o response
Type code se eu usasse o response Mod
jwt eu tô combinando uso fazendo uso do
jar né isso deixa de ser ã desta forma
né A partir de agora
eh o único response mode ã que vai ser
suportado é o fragment né então
Todo mundo vai ter que se preparar nesse
fluxo de autenticação para usar o modelo
fragment então se alguém por exemplo
usasse Code com jwt usasse jarm aí de
novo É um cenário hipotético acredito
que ninguém no ecossistema esteja usando
o jarm eh então ele estaria usando só o
jwt teria que no período de convivência
botar o jwt fragment e após período de
convivência o fragment né paraas
instituições que não definiam response
code response mode no n né
ah você pode
continuar no período de convivência sem
definir o não definir o response mode H
significa automaticamente que query e
fragment são suportados né H mas depois
do período de convivência você teria que
estipular o fragment Ou você já pode no
período de de
de convivência adicional parâmetro mas
precisando manter o query fragment
porque você não tinha antes não definia
antes então você aceitava os dois ã e
até o momento chega no no fap único aqui
hã usando apenas frag né e para quem
tinha múltiplos né múltiplos formatos um
ou mais aqui né H você tem que manter o
o todos os seus suportes todos os os
formatos que você suportava disponível
durante o período de convivência né ã e
depois no no fap BR H você manteria só o
no fap único você manteria só apenas o
FR tal
Ahã outra mudança relevante tá e aqui em
termos de lógica né é o subject Type Eu
tenho dois subject types o Public e o
parse o sub é a forma que você
identifica o
usuário que fez aquela ação que fez
aquela autenticação Então você gera um
ID para ele falando olha o Paulo idx né
fez a autentificação né quando eu falo
Public o ID do Paulo é comum para todos
os participantes do ecossistema então a
instituição a O Paulo é o id1 na
Instituição B O Paulo é id1 não importa
qual participante o público Paulo tem
sempre o mesmo ID quando eu uso per Wise
eh o Paulo pode ter o id1 pro
participante a o ID 20 pro participante
B ou ID 30 pro participante C né Então
esse é um comportamento que também foi
padronizado né ah a partir de do fap
único
Ah vai ser obrigatório o uso do do do
subject Type Public né ã e isso tem
baixo potencial de impacto no
ecossistema mas se alguém faz uso desses
ids né e e eu sei que tem algumas estões
que fazem uso desses ids para mapear
esse dado desse participante ã tem que
ficar atento porque é provável que o
ID deste cliente seja alterado durante
esse processo né porque ele tinha um
ID variado provavelmente agora ele vai
ser público eu posso ter que para fazer
essa mudança né de variado para público
gerar uma mudança de tá então é um ponto
de atenção importante pros clies aqui né
em termos de suporte não é o não eh quem
tem os dois Public parse mantém durante
o período de convivência e depois mantém
apenas o Public tá então aqui é um
pouco de dos principais impactos que
acontecem com a entrada do fap único
pois aqui tem um fac por enquanto
pequeno mas que a ideia é a gente
enriquecer ao longo desse período com as
dúvidas que venham surgindo vocês trazem
que alguém traza traga tá Ah com intuito
de de de uniformizar a comunicação com
todos né todo mundo tem a mesma posição
sobre algum aspectos né então por
exemplo durante o período de convivência
devo aceitar requisições né o DCR para
clientes que forem utilizado fap BR 1.0
né é a uma pergunta que fizeram aqui né
pô faz sentido eu aceitar um DCR num
período de convivência no perfil antigo
né sociar não faz não tem muita lógica
esse cenário né mas você para ele
eliminar mitigar problemas de de
Convivência de
rollbacks que eu fui para Flap único deu
alguma coisa errada de que fazer rack
então sim todo o suporte ao fap BR 1.0
deve ser mantido durante Pero de
convivência inclusive o DC né então isso
tá aqui
Ah então durante o período de
convivência devo aceitar dcm que me leva
ao sentido do fap BR 1.0 sem o fap único
né um dcm que me tira do Private ke me
joga pro TS sim você tem que aceitar
pode ser um rollback de alguém que
tentou fazer e teve algum problema né
então sim Qualquer mudança que esteja
mais indo em direção a fap BR 1.0 ao
invés de fap único também deve ser
aceita porque a gente não sabe qual o
cenário que está vindo ali são um RB ou
não e para identicar problemas vamos
aceitar né após período de convivência
obrigatório remoção suporte ao método de
aut indicação mtls sim né não vai ser
obrigatório o uso do Private jwt com par
então qualquer suporte um outro aspecto
não vai ser mais suportado tem que ser
explicitamente removido para ninguém
mais fazer esse uso
Ahã e daí aqui sobre os parâmetros
revocation point of methods ah
introspection Point se você é obrigado a
declarar não né Isso é uma um
característica opcional que alguns
Alguns participantes declaram mas se
você declarar você tem que seguir as
regras do fap 1 tá então outras
perguntas entram aqui conforme forem
gente
então
Vinício alguém mais tinha tinha um
colega na minha frente aí desculpa pul
desculpa não que eu não tô vendo as mã
tô vendo eu vi que só que tinha uma mão
e eu acho que eu vejo a última que
levantaram por isso pessoal boa tarde o
Guilherme aqui a minha minha pergunta é
somente sobre a publicação dessa página
que a gente tá vendo no portal quando
que ela acontece se ela já tá lá eu eu
não peguei essa parte
ela não tá lá eu vou publicar ela hoje
eu só vou confirmar se é para colocar na
parte do diretrizes operacionais ou se
ponho junto com o perfil de segurança
alap mas a gente manda informe
informando direitinho o link da página
perfeito Muito obrigado pessoal
o a minha dúvida Ô Paulo é com relação
ao eln do
registration do endp de registration né
a gente vai manter o do DCR v1 e V2
durante o período de convivência
tenho certeza entendi é porque a gente
tem no não um end Point do para acionar
né o DCR do inclusive para fazer o dcm
né
e a gente hoje né tá apontando ele para
V2 mas assim é pro pro a partir de Abril
né durante o período de convivência
visto que que o as casas né poderão
acionar o o novo perfil mas se for o
caso voltarem e o nosso eln deveria ter
uma lista então de end points de
registration para dar suporte à ida e à
volta só para entender o seu cenário que
pode ser cenário que a gente não previu
aqui você para suportar o fap único
trocou o authorization server e daí Por
isso você tem um novo registration end
Point né E se você se alguém precisar
fazer um rollback ele deveria usar o
registration Point do servidor de
autorização antigo é ess o cenário e
exato o é porque o o a DC o o Api do DCR
mudou também né
Eh nós tiramos Duas certificações né uma
do para esse perfil novo e a outra pro
DCR V2 né que tem Todas aquelas mudanças
ali com relação à à questão da
criptografia doed token que o colega já
até mencionou ali enfim eh durante o
período de convivência a gente teria que
manter uma lista do tipo a versão um do
DCR a são dois também eu não tenho
certeza que o eln não suporta uma lista
ali tá eh mas acho que essa é uma
discussão que a gente vai ter que levar
pro JT de segurança até anotar aqui
porque não suporta é não suporta né não
suporta então se não suporta Como que o
cara voltaria né se ele não vai ter mais
o se ele não vai ter o conhecimento acho
que esse esse cenário a gente vai ter
que estressar dentro do do GT de
segurança tá o o que tava assim em mente
aqui talvez é que o o a sua URL né de
registration conseguisse definir né ã é
é o é o perfil novo ou o perfil antigo e
eu vou atualizar configurações aqui mas
isso muito em linha de ser o mesmo
autoriz server que tá sendo atualizado
né agora com a troca do autorisation
server de fato Esse é um cenário
possível né que eu não não estressamos
nessa análise eu acho que precisamos dar
uma volta no parafuso para cenário no GT
de segurança até para ver como que vai
ser a tratativa nesses casos
é eu eu realmente eu tava com a ideia de
de subir uma lista né o o eu foi até bom
né conversar com outros colegas aqui
falando que não suporta Agora sim se não
suporta realmente fica essa dúvida né em
caso de rack mas bacana a gente tá na
guarda então ô ô ô Paulo porque eu acho
que esse campo aí ele ele é um campo
importantíssimo né e todo mundo vai ter
que fazer uso dele
né sim é é o caminho para modificar
fazer
se ele tá mudando exato ah precisa ficar
claro como que vai ser esse processo né
tanto de ida e se precisar de rollback
exato É um cenário quando tenho uma
mudança que envolve a criação de novo
autorisation server como que isso
deveria ser feito tá E e daí a discussão
pode ir tanto no rumo de o cliente ter
de alguma forma as duas informações e
saber que usar uma ou outra ou em algum
imperativo do que o o
detentor transmissor ali que tem que se
resolver né então isso precisa ser
discutido no GT de segurança e de fato
não tenho uma resposta aqui para
dar eu entendi eu só tô preocupada com
relação
a os tempos né exato É mas tranquilo a
dúvida era essa então a princípio a
gente mantém só o da V2 né que é o o que
é o tubi aí né digamos assim
né acredito que sim pro go Live né e a
gente discuti essa semana para ver como
que instituições que se encontram nessa
situação de mudança de autoriz server
como elas deveriam se comportar bacana
Paulo só uma dúvida nesse caso aí da
mudança do registration server entendo
que é só url que vai ser alterada
é é porque minha dúvida é se eu vou ter
que fazer algum outro dcm Eh Ou você vai
mudar esse registration Serv você teria
que enviar ele eh pros receptores né pra
gente saber qual URL chamar ou não
porque pelo menos no nosso lado a gente
mantém isso aqui no nosso cadastro né e
a gente utiliza o RL de quando a gente
fez o
DCR acho que essa dúvida foi inclusive
uma dúvida que veio pra gente offline
aqui de uma instituição que mudou teve
que mudar o o registration token como
que elas notificaram os participantes né
Eh dessa mudança né Porque de fato
apesar do não ter o registration token
quando você faz a DCR você recebe a URL
já configurada para fazer alteração e e
muitas soluções guardam essa URL e
deixam de usar a URL que tá no n ali né
então
e é um ponto importante né você tá
mudando
e essa URL precisa ser feita uma
comunicação para todos os participantes
S ter clareza
né isso
obrigado pessoal deu aqui o nosso
horário queria ver se tem mais alguma
dúvida aqui pra gente aproveitar o
esse momento acho que as próximas
semanas vão ser bem importantes aqui
para ecossistema n lembrando a gente
termina o período de convivência ali no
dia 14 dia 15 a gente tem o go Live das
apis de produto então pagamentos v4
pagamentos automáticos v1 eh con
resources V3 de dados do cliente câmbio
v1 então é é bem importante a gente
conseguir sincronizar atender passar por
esse período de convivência então
que reforçando né Canal de comunicação
oficial tanto da estrutura Quanto
bilateralmente é o service desk então
pedir para sempre que vocês tiverem
algum problema alguma questão se vocês
puderem abrir um ticket tanto pra gente
quanto pras instituições é bom que a
gente como ecossistema consegue ter uma
visibilidade do que tá acontecendo se
tem algum problema ou não se a gente
consegue apoiar eh e também ficarem
atentos para ver se não estão abrindo
tickets para vocês também para para
conseguir responder o mais rápido
possível e quer ver se tem mais algum
alguma dúvida aqui aí Paulo se alguma
consideração adicional também não acho
que que é isso acho que por favor en
caminem qualquer dúvida que tiver porque
a dúvida de uma pode ser a dúvida de
muitos aqui e a ideia é a gente tentar
facilitar esse processo que
ele é um processo complexo e a gente tem
mínima margem de erro até zero margem de
erro para garantir uma uma transição sem
Impacto aos clientes finais né então
Eh por favor não não não segurem as
dúvidas compartilhem com a gente pra
gente poder levar pro GT de segurança ou
pro GT que for necessário para discutir
e montar uma
tratativa uma uma última dúvida Ô Paulo
desculpa ah Há possibilidade gente de se
por ventura a gente não tiver sanada
ainda dentro do período de convivência
todos os as questões de segurança adiar
esse esse gol Live das apis pro dia 15
que é um dia depois né da da
da da da enfim do do nosso período aí de
convivência né digamos assim vício não
tá sendo prevista mudança no cronograma
então o ideal é que as instituições
tentem fazer o o os dcms né se adequarem
quanto antes dentro dessa desses quase
20 dias aqui que vai ter de período de
convivência então não deixar pro último
momento porque não tá sendo prevista
nenhuma mudança no go Live tá assim cons
acontecer alguma emergência é algo que
talvez a a gente teria que discutir mas
hoje não não tem essa
previsão não tá ótimo é desejar boa
sorte para todo mundo
aí pessoal boa sorte a todos boa sorte a
todos Obrigada pela presença Pessoal
vocês estão perguntando bastante do
material aqui do link a gente tem uma
questão de governança tá então tá
terminando de ser aprovado pelo conselho
então a gente só precisa verificar se a
gente já pode publicar a versão atual e
qualquer coisa a gente ajusta depois ou
se a gente precisa esperar um número
específico de votos ali dos conselheiros
para publicar mas aí a gente manda o a
gravação a gente consegue disponibilizar
hoje por informa ali no canal do YouTube
do do Open finance E aí a gente vai ver
se já consegue disponibilizar também o
link mas senão nos próximos dias já vai
já vai ser lançado tá é porque é paraa
semana que vem isso aí demorar para dois
trê dias antes a gente não vai a gente
resolver o o mais rápido possível no
nosso caso tem um monte de coisa al que
a gente vai precisar resolver beleza não
pode deixar a gente tá correndo do lado
de cá para para tentar disponibilizar o
mais rápido possível para
vocês pessoal Muitíssimo obrigada boa
semana boa sorte a todos qualquer coisa
estamos à disposição ai através do
service desk e a gente mandou um
formulário aqui também de feedback Então
se vocês puderem responder pra gente
entender como melhorar essas interações
e agradecimento especial aqui ao Paulo e
ao pessoal do GT segurança também que
trabalhou muito aqui para para Live
acontecer Obrigado pessoal boa semana
valeu gente tchau boa semana
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Acesso Exclusivo para Assinantes
Cadastre-se ou faça login com sua conta do Radar Finsiders Brasil para visualizar esta regulação na íntegra, fazer download dos arquivos e ter acesso a relatórios exclusivos do mercado financeiro.