QSealC

Definición

El QSealC (Qualified electronic Seal Certificate) es un certificado eIDAS cualificado que permite a un TPP firmar electrónicamente cada petición HTTP enviada a un banco.

A diferencia del QWAC, que se detiene en la capa TLS, el QSealC opera a nivel de aplicación: la firma viaja en la propia petición y constituye una prueba jurídica oponible de quién envió qué, cuándo y con qué contenido.

QSealC frente a QWAC: firma frente a identificación

Es la dualidad fundamental de la seguridad de la PSD2:

• QWAC — identificación a nivel de transporte (mTLS): «soy realmente Bridge». Desaparece tras el handshake.
• QSealC — firma a nivel de aplicación (HTTP-signature): «aquí está mi petición, sellada, demostrable mañana». Persiste en los logs y las trazas.

En caso de litigio (un pago impugnado), es el QSealC el que el banco exhibirá, no el QWAC.

Cómo funciona la firma

El estándar es el HTTP-signature (adoptado por STET y el Berlin Group):

1. El TPP calcula un hash del cuerpo de la petición (Digest).
2. Selecciona varias cabeceras críticas (request-target, host, date, digest, x-request-id).
3. Las firma con la clave privada asociada al QSealC.
4. La firma se añade a la cabecera Signature.
5. El ASPSP recupera el QSealC (vía keyId), verifica la firma y rejuega el digest.

Cualquier alteración en el camino — aunque sea un solo carácter — invalida la firma y rechaza la petición.

Lo que un QSealC no hace

• No asegura la conexión: ese es el papel del mTLS (con el QWAC).
• No sustituye a la SCA: prueba la identidad del TPP, no la del PSU.
• No firma por sí solo: el TPP debe implementar correctamente la cadena (digest, headers, signature) — olvidar el x-request-id o usar una caja distinta son errores frecuentes.
• No se confunde con una firma personal: es un sello electrónico de una persona jurídica, no de una persona física.

En el ecosistema PSD2

El QSealC es el ladrillo del no repudio: sin él, un TPP podría negar haber enviado una petición, o un atacante podría modificar una solicitud de transferencia en el camino sin detección. Es lo que da valor jurídico al flujo de la PSD2.

Ejemplos concretos

• Caso típico: un PISP (Fintecture, Bridge, Trustly) inicia una transferencia de 12.500 €. El QSealC sella el importe, el IBAN del beneficiario y el timestamp; en caso de impugnación, el banco demuestra al milisegundo lo que el PISP solicitó.
• Emisores: los mismos que para el QWAC (Certigna, Certinomis, D-Trust, InfoCert), a menudo vendidos en pack QWAC + QSealC.
• Errores clásicos: caja de las cabeceras (Digest vs digest), un espacio añadido tras la serialización JSON que cambia el digest, un reloj desincronizado rechazado por el ASPSP.
• Herramientas: las sandboxes de Bridge y STET ofrecen herramientas de volcado de peticiones; en el lado open-source, la librería http-message-signatures (Node, Python, Java) cubre la mayoría de los casos.
• En el lado del ASPSP: la ausencia de un QSealC válido es la primera causa de rechazo en la sandbox — a comprobar de forma prioritaria.