Termos mais procurados:
Na verdade a solução seria a mesma. Tanto é que, atualmente, é preciso que seja feita uma requisição antes sem o certificado onde o erro é esperado. Para só então repetir a requisição com os dados corretos. O mesmo poderia ser feito com o secret. A primeira sem o secret e esperar o erro. Depois repetir. Só seria MUITO mais simples de configurar, de implementar, de manter, além de ser mais compatível por ser menos dependente de configuração de ambiente.
Não é apenas não-repúdio, como há informações financeiras em trânsito, há também questões de sigilo bancário. O próprio BACEN parece amigável a que numa versão 3 o webhook contenha menos dados (por exemplo apenas a chave Pix e o txid) e com isso possa ter requisitos menores de segurança, pois a informação bancária só seria transmitida no GET de /pix ou da cobrança que o causou. Mas para a versão 2.x, ficou assim e não vai mudar.
Sim. Mas o client cert não garante, na prática, neste cenário, nenhuma segurança a mais do que usar um secret, por exemplo. Todos os dados são tunelados com SSL da mesma forma. Só comentei mesmo pelo fato do tabu que existe quando se fala de certificado. Neste caso, ao meu ver, acaba sendo apenas burocracia.
A vantagem de par chave pública/chave privada, como se faz nos certs, é ter uma prova de autoria que só pode ser gerada por uma das partes. Um shared secret pode sofrer replay attack. O certificado é apenas uma forma padronizada e usual de usar criptografia assimétrica, que é a raiz desse processo.
Mas o secret seria tunelado junto no header. Não vejo forma disso ocorrer. Mas enfim... estou nos finalmente da integração e me deparei com essa limitação. O Heroku faz o hand shake SSL utilizando o Amazon Elastic Load Balancers (ELB). Imagino que essa solução venha impactar muita plataforma que esteja hospedada em ambientes PaaS. Seria muito legal ter uma solução para este cenário. Serviria para mim também.
E só completando aqui a ideia do secret. Não há 2 pessoas envolvidas como você citou. Existe só 1 pessoa. A pessoa cria o secret e ela mesma cadastra o webhook no serviço do PSP. Por isso que o conceito é secret mesmo. Se entrarmos no mérito que alguém do PSP pode acessar a base de dados de cadastro de webhooks aí o negócio começa a ficar extremo, pois da mesma forma poderia ter acesso a outras informações pessoais que teriam muito mais valor que um secret de um webhook. E quem garante que a geração das chaves privadas na CA do PSP, que provavelmente não tem certificação oficial de CA, é mais segura que o acesso às informações privadas de uma base de dados de produção? Comentando aqui só para destrinchar mais o assunto... indo além do tabu.
