# QSealC

> Qualified electronic Seal Certificate

The eIDAS certificate that signs every HTTP request from a TPP at the application level. It is the legally enforceable proof that survives proxies, logs and intermediaries.

_Category: securite_

---

## Definition

The **QSealC** (_Qualified electronic Seal Certificate_) is a qualified eIDAS certificate that lets a TPP electronically sign every HTTP request sent to a bank.

Unlike the QWAC, which stops at the TLS layer, the QSealC operates at the application level: the signature travels within the request itself and constitutes legally enforceable proof of who sent what, when and with what content.

## QSealC vs QWAC: signature vs identification

This is the fundamental duality of PSD2 security:

- **QWAC** — identification at the transport level (mTLS): "I really am Bridge." It disappears after the handshake.
- **QSealC** — signature at the application level (HTTP-signature): "here is my request, sealed, provable tomorrow." It persists in logs and traces.

In the event of a dispute (a contested payment), it is the QSealC the bank will produce, not the QWAC.

## How the signature works

The standard is HTTP-signature (adopted by STET and the Berlin Group):

1. The TPP computes a hash of the request body (`Digest`).
2. It selects several critical headers (request-target, host, date, digest, x-request-id).
3. It signs them with the private key associated with the QSealC.
4. The signature is added to the `Signature` header.
5. The ASPSP retrieves the QSealC (via `keyId`), verifies the signature and replays the digest.

Any alteration in transit — even a single character — invalidates the signature and rejects the request.

## What a QSealC does not do

- **Does not secure the connection**: that is the role of mTLS (with the QWAC).
- **Does not replace SCA**: it proves the TPP's identity, not the PSU's.
- **Does not sign on its own**: the TPP must implement the chain correctly (digest, headers, signature) — forgetting `x-request-id` or using a different case are common mistakes.
- **Is not the same as a personal signature**: it is an electronic seal of a legal entity, not of a natural person.

## Within the PSD2 ecosystem

The QSealC is the non-repudiation building block: without it, a TPP could deny having sent a request, or an attacker could alter a transfer request in transit without detection. It is what gives the PSD2 flow its legal value.

```mermaid
sequenceDiagram
    participant TPP as TPP
    participant ASPSP as ASPSP

    Note over TPP: Building the request
    TPP->>TPP: 1. Computes Digest(body)
    TPP->>TPP: 2. Selects headers to sign
    TPP->>TPP: 3. Signs with QSealC key
    TPP->>TPP: 4. Adds Signature header

    Note over TPP,ASPSP: Sent via mTLS (QWAC)
    TPP->>ASPSP: POST /payment-requests + Signature

    Note over ASPSP: Verification
    ASPSP->>ASPSP: 5. Retrieves QSealC via keyId
    ASPSP->>ASPSP: 6. Verifies signature
    ASPSP->>ASPSP: 7. Recomputes Digest(body)

    alt Valid signature
        ASPSP->>TPP: 200 OK + paymentRequestId
    else Invalid signature
        ASPSP->>TPP: 401 / 403
    end
```

## Real-world examples

- **Typical case**: a PISP (Fintecture, Bridge, Trustly) initiates a €12,500 transfer. The QSealC seals the amount, the beneficiary IBAN and the timestamp; in the event of a dispute, the bank can prove to the millisecond what the PISP requested.
- **Issuers**: the same as for the QWAC (Certigna, Certinomis, D-Trust, InfoCert), often sold as a QWAC + QSealC bundle.
- **Classic errors**: header case (`Digest` vs `digest`), a space added after JSON serialisation that changes the digest, a desynchronised clock rejected by the ASPSP.
- **Tools**: the Bridge and STET sandboxes offer request-dump tools; on the open-source side, the `http-message-signatures` library (Node, Python, Java) covers most cases.
- **On the ASPSP side**: the absence of a valid QSealC is the leading cause of rejection in the sandbox — to be checked first.

## Sources

- [Regulation (EU) No 910/2014 (eIDAS) — qualified electronic seals](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014R0910) — EUR-Lex
- [EBA opinion on eIDAS certificates under PSD2 RTS](https://www.eba.europa.eu/sites/default/files/documents/10180/2545547/4d3a6b7e-c5a1-4ce5-a73b-8ba12c39e92e/EBA%20Opinion%20on%20the%20use%20of%20eIDAS%20certificates%20under%20the%20RTS%20on%20SCA%20and%20CSC.pdf) — European Banking Authority, 2018-12-10

---

Source: https://openfinanceguide.com/en/glossary/qsealc