Histórico de mensagens em sugestões

Tenho essa mesma dúvida...

e qual o risco que existe para o PSP em mandar um request pra uma URL sem mTLS que não existe com o mTLS? é o EC que tem que confiar ou não. tinha que ser opção do EC.

Na verdade, .webhook.pix.ae. Precisa do servername para decidir qual certificado apresentar.

webhook.pix.ae

se a Gerencianet considerar interessante e topar me recomendar, começo já a fazer 😆

Ah sim, pois a transfere a lógica do transporte para a aplicação. Eu ainda não sei afirmar se isso foi consequência de não pensar em ambientes desse tipo, ou by design de achar que esses ambientes seriam um risco sistêmico maior.

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 😝

jwt é dividido em 3 partes separadas por um ponto (parteA.parteB.parteC). pega a parteB, dá um decode (base64) e pronto. é só ignorar o resto (o certo seria validar a assinatura do conjunto, mas não fazem isso)

Mas pelo menos será factível. Esse problema de hospedagem compartilhada, de não poder mexer no nginx pois aplicaria-se o mtls em tudo, o cliente não tá tendo pra onde correr...

https://tenor.com/view/fortune-teller-crystall-ball-psychic-clairvoyant-gif-5100696
Minha percepção extra-sensorial diz que o povo vai apanhar para decodificar (validando) JWT

abrir é fácil. o que é difícil é validar a assinatura (e quem tiver dificuldade vai simplesmente ignorar, o que é mais inseguro)

Pra nós, tecnicamente, tudo bem em enviar somente txid. Mas se tiver uma forma de já entregar a informação completa pro EC, melhor ainda...

a ideia é boa, eu sugeri no github e não aprovaram. mas insistir não custa...

Pode ser, considerando-se o próprio client_secret como key.

Mudar de JSON para JWT ? Só precisa ver se o povo vai conseguir abrir JWT direito... até os PSPs estão sofrendo.

seria o ideal, na minha opinião

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

#brainstorm

E se viesse tudo o que vem hoje, porém criptografado com o client_secret? (teoricamente é uma informação que só a gn conhece)

Na verdade, chave Pix e txid, para evitar o problema do webhook pilantra. 😉

Mas isso acho que só com simplificação mesmo. Se não tem mTLS, teria que vir sem informação quase nenhuma, só um txid para ir lá e dar um GET.