Definição
O QSealC (Qualified electronic Seal Certificate) é um certificado eIDAS qualificado que permite a um TPP assinar eletronicamente cada requisição HTTP enviada a um banco.
Ao contrário do QWAC, que para na camada TLS, o QSealC opera no nível aplicativo: a assinatura viaja na própria requisição e constitui uma prova jurídica oponível de quem enviou o quê, quando e com qual conteúdo.
QSealC vs QWAC: assinatura vs identificação
É a dualidade fundamental da segurança da PSD2:
- QWAC — identificação no nível de transporte (mTLS): "eu sou mesmo a Bridge". Desaparece após o handshake.
- QSealC — assinatura no nível aplicativo (HTTP-signature): "aqui está minha requisição, selada, comprovável amanhã". Persiste nos logs e nos rastros.
Em caso de litígio (pagamento contestado), é o QSealC que o banco apresentará, não o QWAC.
Como funciona a assinatura
O padrão é o HTTP-signature (adotado pela STET e pelo Berlin Group):
- O TPP calcula um hash do corpo da requisição (
Digest). - Ele seleciona vários cabeçalhos críticos (request-target, host, date, digest, x-request-id).
- Ele os assina com a chave privada associada ao QSealC.
- A assinatura é adicionada ao cabeçalho
Signature. - O ASPSP recupera o QSealC (via
keyId), verifica a assinatura e reexecuta o digest.
Qualquer alteração no caminho — até um caractere — invalida a assinatura e rejeita a requisição.
O que um QSealC não faz
- Não protege a conexão: esse é o papel do mTLS (com o QWAC).
- Não substitui a SCA: ele prova a identidade do TPP, não a do PSU.
- Não assina sozinho: o TPP deve implementar corretamente a cadeia (digest, headers, signature) — esquecer o
x-request-idou usar uma caixa diferente são erros frequentes. - Não se confunde com uma assinatura pessoal: é um selo eletrônico de uma pessoa jurídica, não de uma pessoa física.
No ecossistema PSD2
O QSealC é o bloco da não repúdio: sem ele, um TPP poderia negar ter enviado uma requisição, ou um atacante poderia modificar um pedido de transferência no caminho sem ser detectado. É o que confere valor jurídico ao fluxo da PSD2.
Exemplos concretos
- Caso típico: um PISP (Fintecture, Bridge, Trustly) inicia uma transferência de 12.500 €. O QSealC sela o valor, o IBAN do beneficiário e o timestamp; em caso de contestação, o banco prova ao milissegundo o que o PISP solicitou.
- Emissores: os mesmos do QWAC (Certigna, Certinomis, D-Trust, InfoCert), muitas vezes vendidos em bundle QWAC + QSealC.
- Erros clássicos: caixa dos headers (
Digestvsdigest), espaço adicionado após a serialização JSON que muda o digest, relógio dessincronizado rejeitado pelo ASPSP. - Ferramentas: os sandboxes da Bridge e da STET oferecem ferramentas de dump de requisição; no lado open-source, a lib
http-message-signatures(Node, Python, Java) cobre a maioria dos casos. - No lado do ASPSP: a ausência de um QSealC válido é a principal causa de rejeição no sandbox — a verificar com prioridade.