Los dos certificados salen del mismo eIDAS TSP, llevan el mismo número de autorización y los mismos roles DSP2, y a menudo llegan en el mismo pedido. La diferencia no está en lo que contienen. Está en la capa de la pila que los lee. El QWAC lo lee la capa TLS, una vez, en el handshake. El QSealC lo lee la capa aplicativa, en cada petición, en una cabecera HTTP.
Un ticket que dice «error de certificado» sin decir en qué capa no es diagnosticable. Este artículo no redefine los dos objetos — las fichas QWAC, QSealC y mTLS ya lo hacen. Sitúa cada uno en la pila, en la infraestructura y en los logs, con el texto de STET 1.6.3 en paralelo. Para el panorama completo del stack, lea antes Arquitectura técnica de una API DSP2.
En una imagen: dos capas, dos certificados
Una petición DSP2 baja por la pila. Cada certificado interviene en un solo nivel.
| QWAC | QSealC | |
|---|---|---|
| Base eIDAS | certificado cualificado de autenticación de sitio web, art. 3(39) | certificado cualificado de sello electrónico, art. 3(30) |
| Capa | transporte (TLS) | mensaje (HTTP) |
| Leído por | la pila TLS de ambos lados, en el handshake | el verificador de firma del ASPSP, en cada petición |
| Frecuencia | una vez por conexión | una vez por petición — y por respuesta si el ASPSP firma |
| Sobrevive a un proxy que termina TLS | no | sí |
| Valor probatorio a posteriori | ninguno: no se conserva nada | la firma queda en la petición, verificable más tarde |
| Clave privada, lado TPP | donde se abre la conexión saliente | donde se construye la petición |
| Síntoma cuando falla | handshake roto, ningún código HTTP | HTTP 400 (STET §3.5) |
| Lo que dice STET | §3.1, §3.2, §3.9 | §3.5 |
La RTS (UE) 2018/389, art. 34, admite uno u otro para la identificación. Los estándares de API zanjaron la cuestión apilándolos: STET y Berlin Group exigen el QWAC para el canal y el QSealC para la firma. Dos certificados, por tanto dos claves privadas, dos fechas de expiración y dos procedimientos de rotación.
Lo que exige STET, texto en mano
Bastan tres pasajes del Framework 1.6.3 (Part 1). Las páginas son las del PDF oficial, que el manual muestra al margen de cada párrafo.
§3.1 y §3.2 — el QWAC, para TLS y nada más
«Each actor must be provided with at least one eIDAS certificate (QWAC), for TLS 1.2 purpose» (§3.1, p. 17). El TPP verifica el QWAC de servidor del ASPSP y presenta el suyo; ambos respetan ETSI TS 119 495; «in case of authentication failure, on one side or the other, the connection must be closed»; y «no additional encrypting or authenticating feature is required» (§3.2, p. 17–18). El QWAC nunca sube hasta la petición: todo lo que tiene que decir, lo dice en el handshake.
El mismo párrafo fija el formato del organizationIdentifier del sujeto del certificado: PSD, el código de país de la NCA, un guion, el identificador de la NCA, un guion, el número de autorización — PSDFR-ACPR-12345 para un actor autorizado por la ACPR. Es ese campo, junto con los roles del QC statement ETSI, lo que el ASPSP lee en el certificado de cliente para saber quién llama, y en calidad de qué.
§3.5 — el QSealC, para firmar cada petición
«Each request sent by the TPP has to be signed and ASPSP might also sign their responses. If the ASPSP notes that the signature is either absent or invalid for a given request, it shall reject this request with HTTP400» (§3.5, p. 53).
El mecanismo histórico es HTTP Signature en su versión draft-cavage: un Digest SHA-256 del cuerpo, y luego una firma RSA-SHA256 hecha con el QSealC sobre (request-target), Date, Content-Type, Content-Length, X-Request-Id, las cabeceras PSU-* y el propio Digest, transportada en la cabecera Signature con keyId, algorithm y la lista de cabeceras firmadas (§3.5.1.1, p. 53–55). El keyId es o bien el identificador asignado durante el registro OAuth2, o bien la URL del QSealC sufijada con un _ y su huella SHA-256 (§3.5.1.2, p. 55).
Desde la 1.6.3, el Framework aconseja sustituir este mecanismo por el perfil JSON Web Signature de Open Banking Europe: un JWS separado (RFC 7515) en la cabecera x-jws-signature, cuya cabecera protegida lleva x5t#S256, la huella del QSealC firmante, y sigD, la lista de cabeceras cubiertas (§3.5.2, p. 55–56). El draft-cavage, por su parte, ha sido reemplazado en el IETF por la RFC 9421 — que STET no cita como objetivo.
§3.9 — el QWAC vuelve una tercera vez, en OAuth2
«Based on MTLS, the identity of the TPP is provided by its eIDAS certificate during OAuth2 procedures», con remisión a la RFC 8705 (§3.9, p. 59). El servidor de autorización autentica por tanto al cliente mediante tls_client_auth — el QWAC presentado en el handshake del POST /token — y puede vincular el token emitido a ese certificado, a través de su claim cnf y la huella x5t#S256. Un token vinculado a una huella que ya no es la presentada se rechaza, aunque no haya expirado.
Una petición, tres verificaciones
Tres verificaciones, tres capas, tres síntomas que no se parecen en nada. El orden de las dos verificaciones aplicativas es propio de cada banco; el síntoma, en cambio, no cambia.
Dónde viven las claves privadas: el error de capa
Aquí es donde uno se equivoca. Las dos claves privadas no viven en el mismo sitio, porque los dos certificados no los lee el mismo componente.
Del lado del TPP, en salida
La clave del QSealC pertenece al componente que construye la petición, porque la firma cubre cabeceras — Date, Content-Length, X-Request-Id — que deben quedar fijadas antes del envío. La clave del QWAC pertenece al componente que abre la conexión. Si un proxy saliente, un NAT aplicativo o un service mesh abre las conexiones en lugar de la aplicación, es él quien presenta el QWAC, y la aplicación no tiene por qué guardar su clave. Poner la clave del QWAC en la aplicación cuando el mesh termina y reabre TLS da un handshake sin certificado de cliente: una alerta TLS, y ningún código HTTP.
Del lado del ASPSP, en entrada
Del lado del banco, el QWAC de cliente se detiene en el componente que termina TLS. Lo que pasa después es una identidad extraída — organizationIdentifier, roles, huella — transmitida en una cabecera interna que el resto de la cadena tiene que poder creer, de ahí el interés de firmarla o de aceptarla solo del terminador. La firma QSealC, en cambio, lo atraviesa todo: un componente situado en cualquier punto por detrás puede verificarla, a condición de ver los bytes originales. Una gateway que reserializa el JSON, recalcula Content-Length o normaliza Date antes del verificador produce 400 en peticiones válidas.
Las seis confusiones de capa
| # | Confusión | Qué ocurre | Síntoma |
|---|---|---|---|
| 1 | Clave del QWAC en un componente que no abre la conexión | handshake sin certificado de cliente | alerta TLS, sin HTTP |
| 2 | QSealC presentado como certificado de cliente TLS, o QWAC usado para firmar | el QcType ETSI no es el correcto (web para uno, eseal para el otro); un verificador que lo controle rechaza | alerta TLS, o 400 |
| 3 | Firma calculada antes de un proxy que reescribe Date, Content-Length o el cuerpo | la firma cubre otros bytes que los recibidos | 400, firma inválida |
| 4 | Verificación hecha después de una transformación de la petición, del lado del ASPSP | misma causa, en espejo | 400 en peticiones válidas |
| 5 | QWAC renovado sin reemitir los tokens vinculados | cnf.x5t#S256 ya no corresponde al certificado presentado | 401 con un token no expirado |
| 6 | CA del QTSP del banco ausente del almacén de confianza del TPP | el TPP rechaza el QWAC de servidor del ASPSP | unknown_ca, conexión cerrada por el propio TPP |
La confusión 2 es la más costosa, porque es invisible mientras el banco no controle el tipo de certificado — y visible de golpe el día en que lo haga. Los dos certificados se venden a menudo juntos; no son intercambiables.
Matriz de diagnóstico
| Síntoma | Capa | Certificado implicado | Dónde mirar |
|---|---|---|---|
Conexión cerrada durante el handshake, ningún código HTTP; handshake_failure, bad_certificate, certificate_expired, unknown_ca | TLS | QWAC — el suyo, o el del banco que usted no reconoce | logs del terminador TLS; openssl s_client -cert -key |
| 401 | token | QWAC, vía el binding RFC 8705; o simplemente un token expirado | respuesta del servidor de autorización; cnf del token frente a la huella del certificado presentado |
| 400 que menciona la firma (STET §3.5) | mensaje HTTP | QSealC | Digest recalculado; lista de cabeceras firmadas; keyId resoluble; bytes realmente enviados |
| 403, o código de negocio del banco | autorización | ninguno de los dos | roles PSD2 del certificado frente al endpoint llamado; estado del consentimiento |
Dos relojes
Los dos certificados expiran cada uno en su fecha, son revocables cada uno por su lado y se renuevan por separado. Tres consecuencias:
- Dos alertas de expiración, no una. Un QWAC válido no dice nada del estado del QSealC, y a la inversa.
- La rotación del QWAC afecta a los tokens. El registro OAuth2 sobrevive si el DN del sujeto no cambia — es el que declara
tls_client_auth_subject_dn— pero los access tokens vinculados a la huella antigua (RFC 8705) ya no pasan. Reemitir los tokens forma parte de la rotación. - La rotación del QSealC afecta al
keyId— cambia la URL sufijada con la huella, o elx5t#S256del perfil JWS — y no debe retirar el certificado antiguo: las peticiones ya firmadas deben seguir siendo verificables. Es todo el sentido del no repudio. Se retira la clave privada, se deja el certificado publicado.
Para resumir
- QWAC = capa TLS. Se lee en el handshake, por el componente que abre o termina la conexión. Su clave vive ahí, y en ningún otro sitio.
- QSealC = capa de mensaje. Se lee en cada petición, por un verificador que debe ver los bytes originales. Su clave vive donde se construye la petición.
- STET: QWAC para TLS 1.2 (§3.1–3.2), cada petición firmada con el QSealC y 400 en caso contrario (§3.5), perfil JWS recomendado desde la 1.6.3 (§3.5.2), identidad OAuth2 aportada por el QWAC (§3.9, RFC 8705).
- Sin código HTTP → QWAC. 400 → QSealC. 401 → binding del token. 403 → ninguno de los dos.
- Dos relojes: dos expiraciones, dos rotaciones, y el QSealC antiguo sigue publicado para verificar el pasado.
Para el resto del stack — estándares, flujos SCA, consentimiento — véase Arquitectura técnica de una API DSP2. Los dos mecanismos de firma, byte a byte, y los fallos de handshake más frecuentes son objeto de los dos artículos siguientes. El texto íntegro de la sección citada está en el manual STET 1.6.3, con el PDF original en paralelo.