Técnico

HTTP Signature

HTTP Message Signatures (RFC 9421) — assinatura aplicacional HTTP

Padrão IETF (RFC 9421, finalizado em 2024) que define um mecanismo de assinatura no nível das requisições e respostas HTTP. Oferece integridade/autenticidade aplicacional complementar ao TLS, exigida pela RTS-CSC da PSD2 para os TPPs na UE (assinada com um QSealC).

Definição

HTTP Message Signatures (ou HTTP Signature) é um padrão IETF finalizado na RFC 9421 (fevereiro de 2024) para assinar requisições e respostas HTTP.

Ele acrescenta integridade e autenticidade aplicacionais como complemento ao TLS: mesmo que o TLS proteja o transporte, a assinatura prova que uma mensagem HTTP precisa foi de fato emitida por um ator identificado, sem modificação. É o padrão de referência na RTS-CSC da PSD2, em que os TPPs assinam suas requisições de API com um QSealC (eIDAS), assim como do lado do Berlin Group e do STET.

Antes da RFC 9421, o setor usava o antigo draft Cavage (draft-cavage-http-signatures), próximo, porém não definitivo; a RFC 9421 o moderniza (labels, structured fields, Content-Digest).

Por que a HTTP Signature

O TLS protege entre os dois endpoints, mas não além: uma requisição interceptada por um proxy, registrada em log, reproduzida ou modificada fora do túnel deixa de ter qualquer garantia. A assinatura aplicacional:

  • protege contra modificações intermediárias;
  • assegura o não repúdio (é impossível negar ter enviado uma mensagem assinada);
  • sobrevive a proxies, caches e dumps de logs;
  • permite uma verificação assíncrona (auditoria, replay, depuração).

É o equivalente do PAdES para o PDF, mas aplicado às APIs HTTP.

Estrutura de uma requisição assinada (RFC 9421)

POST /payments HTTP/1.1
Host: api.bank.fr
Content-Type: application/json
Content-Length: 423
Date: Sat, 19 Apr 2026 10:30:00 GMT
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Signature-Input: sig1=("@method" "@target-uri" "host" "date" "content-digest");\
                  alg="rsa-pss-sha512";\
                  keyid="qsealc-key-1";\
                  created=1714000000
Signature: sig1=:VXYZ12345...base64...:
 
{ "instructed_amount": { "currency": "EUR", "amount": "100.00" }, ... }

Os componentes: Content-Digest (hash SHA-256 do corpo), Signature-Input (o que é assinado: método, URI, headers, além de alg, keyid, timestamp) e Signature (a assinatura em base64). Algoritmos recomendados: rsa-pss-sha512 (FAPI / PSD2), ecdsa-p256-sha256 (mobile), ed25519.

O fluxo PSD2 + QSealC

O QSealC (Qualified Seal Certificate, eIDAS) serve para assinar uma mensagem em nome de uma pessoa jurídica (o TPP). O TPP assina com sua chave privada, o ASPSP verifica a assinatura e a cadeia de confiança (QSealC → TSP qualificado → EU LOTL) e, em seguida, confronta o registro da EBA para confirmar que o TPP de fato possui o papel exigido.

RFC 9421 vs draft Cavage

AspectoCavage (antes de 2024)RFC 9421 (2024+)
StatusDraft IETFRFC estável
Nomenclatura(request-target), (created)@method, @target-uri
MultiassinaturasDifícilNativa (labels)
Structured fieldsNãoSim (RFC 8941)
DigestHeader Digest (RFC 3230)Content-Digest (RFC 9530)
Adoção UE PSD2CavageMigração para a 9421 em curso

Casos de uso

  • PSD2 / Open Banking: assinatura das requisições TPP → ASPSP (PIS, AIS, CBPII) e, às vezes, das respostas.
  • eHealth: assinatura entre atores de saúde (DMP, Mon espace santé).
  • Webhooks: Stripe, GitHub e Slack assinam seus webhooks (HMAC ou uma abordagem semelhante à RFC 9421).
  • Marketplaces de API B2B: Apigee e Kong suportam HTTP Signature para uma autenticação forte.

O que a HTTP Signature não é

  • Não é um substituto do TLS: é um complemento aplicacional; o TLS continua obrigatório.
  • Não é criptografia: é assinatura (integridade + autenticidade); para a confidencialidade, veja o JWE.
  • Não é obrigatória para o OAuth: os access tokens funcionam sem ela, mas o FAPI 2.0 os combina.
  • Não é mTLS: o mTLS autentica o canal, a HTTP Signature autentica a mensagem — complementares.
  • Não é um formato universal: a variante Cavage continua muito presente.

No ecossistema PSD2 / Open Finance

HTTP Signature + QSealC é a abordagem europeia da segurança de API da PSD2:

  • Berlin Group: exige os headers Signature + Digest, muitas vezes no estilo Cavage.
  • STET: assinatura + digest + X-Request-ID.
  • OBIE UK: usa uma JWT detached signature (diferente, mesmo espírito).
  • PSD3 / FIDA: devem padronizar na RFC 9421 com QSealC e convergir para o FAPI 2.0.

Exemplos concretos

  • Bridge: assina suas requisições aos bancos FR com QSealC (estilo Cavage, em migração para a RFC 9421).
  • Fintecture: assina suas requisições de PIS para BNP, SG, BPCE.
  • Tink: assina na UE e no Reino Unido (perfil duplo).
  • Webhooks Stripe: Stripe-Signature: t=...,v1=hmac_sha256_hash.
  • Webhooks GitHub: X-Hub-Signature-256: sha256=... (HMAC).
  • Ferramentas: http-message-signatures (Python, Node), plugins Apigee, Kong, Tyk.
  • Migração: os ASPSPs europeus migram para a RFC 9421 ao longo de 2025-2027, mantendo o Cavage em paralelo.
  • Custo: para um TPP, a integração leva algumas semanas, mas a gestão das chaves QSealC (HSM) é o principal desafio operacional.

Veja também: Manual STET

Fontes

Aprofundar

No blog

Leituras mais completas para ir além da definição.

7 de abril de 2026
técnico

Arquitetura técnica de uma API DSP2: o que é preciso saber antes de escrever a primeira linha de código — Ler o artigo

Panorama técnico da DSP2 para CTOs, desenvolvedores e PMs técnicos: padrões de API, segurança (mTLS, certificados eIDAS), OAuth2, fluxos SCA, gestão do consentimento, armadilhas de implementação.

6 de abril de 2026
regulação

Entender a PSD2: o que ela muda para seus clientes e seu negócio — Ler o artigo

Tudo o que um dirigente, um product manager ou uma equipe de negócios precisa entender sobre a PSD2 (DSP2). Atores, consentimento, oportunidades, sem jargão técnico.