Histórico de mensagens sobre callback em sugestões

Agora, vale sim uma flexibilização desse callback num v3. Certamente levaremos isso ao BC.

É que a discussão começou na checagem do teste e foi para o mTLS dos callbacks...

No caso do callback, espera-se que o cliente valide o certificado: seja na camada de transporte ou aplicação. É isso que a gente quer permitir: deixar o cliente escolher. Entendemos que a validação do PUT está impedindo isso, ou pelo menos atrapalhando na fluidez.

Sim, mas o ponto era tirar mTLS dos callbacks... aí que ultrapassa o regramento.

talvez com um contrato específico, como você falou antes + a retirada de informações do callback (deixar só chave + txid se houver), aí o EC teria que consultar a API, creio que seja possível o BACEN aprovar

Se o callback retornar qualquer coisa diferente de status 200, considera falha e faz retentativas?

a questão do cliente precisar ter mTLS é relativamente fácil de contornar. eu poderia oferecer um serviço que recebe o callback com mTLS e repassa pro EC sem essa exigência, por exemplo 😝

acho que faz sentido. se for uma renúncia do cliente, a GN nao está deixando de cumprir com a determinação de segurança do BACEN. levem ao Bacen pra ver no que dá.

mas até que o Bacen confirme isso, eu vejo essa possibilidade de bypass (seja no PUT ou no próprio callback) como uma mera facilitação do processo de cadastro do webhook (útil principalmente quando tem um terceiro no processo, além da GN e o EC). não vejo utilidade prática nenhuma enquanto o Bacen exige mTLS nos callbacks

Agora, o ideal mesmo seria o BC flexibilizar o mTLS no callback. Usufrui dessa segurança quem quiser. E aí vejo que entraria perfeitamente no gn/config (caso não haja endpoint específico da spec pra isso)...

Deixe-me explicar melhor. Precisamos, de qualquer forma, flexibilizar o PUT. Não queremos remover funcionalidade dele, simplesmente permitir o bypass.

Poderíamos tirar do PUT e levar para o callback? Sim, porém enxergamos como ponto negativo remover uma feature dele (mesmo que seja aplicada em outro ponto).
Isso não impede que iniciemos outra discussão: melhorias no callback.

Sim, entendi o seu ponto. A questão é mexer o menos possível no PUT, nesse momento. Sem remover funcionalidades dele, mas dando uma flexibilizada. Certamente voltaremos a falar do callback.

bom, é útil em qualquer um dos dois jeitos. só não entendi o argumento pra ser favorável a ser no PUT e nao no callback.

o argumento a favor de ser no callback é já ficar preparado pra eventual liberação da necessidade do mTLS por parte do BACEN.

outro argumento é permitir que clientes que vão receber callback usando APIs operadas por terceiros (como ERP SaaS) possam adicionar o header quando bem entenderem, sem depender de mudança na API que manda o PUT

Desativar de vez somente no callback.

No caso de implementar no ato do callback, eu tô pensando mesmo é em deixar o integrador desativar de vez, se assim permitir a spec.

e o integrador tb pode "só enviar um header e pronto" na hora que recebe o callback, da mesma forma.. qual a dificuldade?

e se o BACEN resolver tornar o mTLS opcional (vai que....) o lado que recebe o callback vai poder dar o bypass de forma mais fácil do que alterando o script que consome a API

ou seja, o header seria enviado pelo script que RECEBE o callback e não pelo script que consume o PUT /webhook

hoje:
- GN envia "callback" simulado sem certificado (se for aceito pelo integrador, é uma falha; dá "break" aqui)
- GN envia "callback" simulado com certificado (que deve retornar 200)

poderia ficar assim:
- GN envia "callback" simuilado sem certificado:
--> se receber de volta 200 + um header x-mtls-bypass: true, tá ok e dá break;
--> se receber de volta 200 sem o header, é falha e dá break;
--> se receber de volta 4xx, segue adiante
- GN envia "callback" simulado com certificado (que deve retornar 200)

a proposta da GN é passar o header x-mtls-check: false na hora de fazer o PUT /webhook. esse header poderia ser enviado pelo servidor/script que recebe os callbacks

Se for assim, penso que incluir a tarifa no callback tem que ser colocado com um nome mais especifico também