QWAC vs QSealC
eIDAS defines two kinds of qualified certificate issued to legal persons: the QWAC (qualified website authentication certificate) and the QSealC (qualified certificate for electronic seals). They come from the same kind of issuer and look alike on casual inspection, but they authenticate different things and are used at different layers.
Side by side
| QWAC | QSealC | |
|---|---|---|
| Authenticates | A website: domain name(s) plus the legal entity operating them | A legal entity as the origin of sealed data |
| Used in | The TLS handshake, like any server certificate | Electronic seals over documents, messages or API payloads (application layer) |
| eIDAS basis | Article 45, Annex IV | Articles 35–38, Annex III |
| QcType (ETSI EN 319 412-5) | id-etsi-qct-web0.4.0.1862.1.6.3 | id-etsi-qct-eseal0.4.0.1862.1.6.2 |
| Validation policy | POLICY_EIDAS_QWAC_V1 | POLICY_EIDAS_QSEALC_V1 |
qualified.qcType in the result | QC_TYPE_WEB | QC_TYPE_ESEAL |
A seal is the legal-person counterpart of a signature: it asserts that data originated from the named organisation and has not been altered, rather than binding it to a natural person. That is why a QSealC never appears in a TLS handshake and a QWAC never seals a document — the certificate types encode that intent in their QcType and key-usage profiles, and a validation policy checks the type it is given.
Where PSD2 uses each
Under the PSD2 regulatory technical standards (Delegated Regulation (EU) 2018/389, Article 34), third-party providers identify themselves to account-servicing payment service providers using qualified certificates:
- QWACs identify the parties at the transport layer — the TPP's TLS client (or the bank's server) presents one in the handshake.
- QSealCs seal the application-level request or response, so its origin and integrity can be shown after the connection is gone.
Either type can carry the PSD2 statement from ETSI TS 119 495: the provider's payment-service roles and the competent authority that authorised it (name and id). The authorization number is carried in the subject's organizationIdentifier (e.g. PSDNL-DNB-123456), not in the statement itself. The validation result surfaces all of them together in the psd2 block — roles as PSD2_ROLE_* values (the PSD2_ROLE_PSP_* payment-service roles from PSD2, plus the two PSD2_ROLE_VOP_* verification-of-payee roles), plus ncaId, ncaName and authorizationNumber. The attributes are read from the certificate; national competent authority and EBA registers are not cross-checked, so a certificate's validity is not proof of a live regulatory authorisation.
Telling them apart
Read the QcType. Everything else — issuer style, subject attributes, even the PSD2 statement — can look identical across the two types. Validate the certificate under the policy matching its intended use and the result's qualified.qcType reports what the certificate actually is; a certificate of the wrong type for the policy comes back VERDICT_INVALID with SUB_INDICATION_WRONG_QC_TYPE. Note that qualified.isQualified still reports whether the certificate is an EU qualified certificate at all — a QSealC validated under the QWAC policy is still qualified, just not a QWAC — so gate on the verdict, not on isQualified.
Related
- What is a QWAC? — the website-authentication half in depth.
- How qualified status is determined — the trusted-list procedure both types go through.
- API quickstart — validate either type with one POST.