Decide whether the seal signs the payload or wraps it

[LKSNDRTMLKV]

Question

SealPort today assumes one shape: a finished JWS is produced, a digest is taken over it, and a detached qualified seal comes back alongside. Two artefacts — the payload signs itself, the seal attests it separately.

Selective disclosure assumes the other shape. In SD-JWT VC the credential carries an x5c chain including the qualified seal certificate, so the SD-JWT is the sealed object and the seal is its signature. One artefact.

These are not variations on a theme. They imply different port contracts, different verification stories, and different answers to "what exactly does the seal attest".

Why it blocks

Selective disclosure is the fix for a real defect: disclosure signatures are frozen per redaction pattern, so reclassifying a field breaks verification for every affected passport at once. See the x-disclosure work for the mitigation that is in place, and note it mitigates rather than removes.

Adopting SD-JWT is the removal. But building it against the wrong seal shape means the port is wrong, so this decision precedes the code.

What settles it

Whether a qualified seal can be obtained as a JOSE/JWS signature under the seal certificate, rather than only as a document-format seal (CAdES/PAdES/XAdES) over bytes.

• If yes — the seal becomes the SD-JWT's signature. SealPort changes from "seal these bytes" to "sign this payload", and several existing decisions get revisited: the digest-over-the-JWS-string choice, the declared mimetype, the extensionless filename.
• If no — SD-JWT can still be adopted, but as a non-qualified layer inside a sealed envelope. It solves the disclosure problem and does not inherit the seal's legal weight. Existing decisions stand.

Also open, and larger

Who holds the certificate. A seal attests the origin of what it covers, so whoever holds it is making a claim about content they may not have authored. That is a question about the product's role, not about the format, and it may change the answer above regardless of what is technically possible.

Not blocked on this

The x-disclosure mitigation, the field-level backstop, and the demonstration test all stand on their own and are already merged or in review.

[LKSNDRTMLKV]

Overlaps #80, which raised SD-JWT-VC selective disclosure on 2026-07-31 — I opened this without checking for it first. #80 is the broader question (adopting SD-JWT VC at all, including holder presentation); this one is the narrower blocker underneath it (whether a qualified seal can be the SD-JWT's signature, or only wrap it). Keeping both, since the blocker can be answered independently and its answer constrains #80.

[LKSNDRTMLKV]

The question is answered: yes

ETSI TS 119 182-1 (current version v1.2.1, 2024-07) specifies a JSON format for AdES signatures built on JWS (IETF RFC 7515), and its stated aim is that such signatures can be used to meet the requirements of electronic seals, advanced electronic seals and qualified electronic seals as defined in Regulation (EU) No 910/2014.

So a qualified seal does not have to arrive as a document-format seal over bytes. JAdES is the JSON-native profile and is a full eIDAS citizen. The "if yes" branch is open at the standards level.

What that does not establish is that a given provider will sell one, and that is where the decision actually turns.

Why the recommendation is still Wrap

Three things, in increasing order of how much they bind:

1. Availability, not permission, is the constraint. A JSON-native seal requires a QTSP that issues JAdES. Providers commonly return CAdES only. The standards objection is gone; the procurement one is not.

2. It interacts with who holds the certificate — the "also open, and larger" section of this issue. If certificates name individual operators rather than one party covering everyone, then operators may sit across many providers, and we cannot require all of them to offer JAdES. The more operator-sovereign the certificate model, the less tenable a JAdES requirement becomes. That coupling means this issue cannot be closed independently of the certificate-holder question, only conditioned on it.

3. capabilities() already negotiates this per adapter, and SealFormat already carries Jades. The design that survives either answer already exists, which is the strongest argument for not choosing now: nothing is being foreclosed by waiting, and something would be foreclosed by committing.

Recommendation: build Wrap, keep Sign reachable. Revisit when a JAdES-capable provider is contracted and the operator population is known.

The known break, recorded rather than discovered

SealRequest.payload_hash is a SHA-256 digest. A JWS signature cannot be produced from a digest — JWS signs payload bytes. So the Sign branch is not merely undecided, it is unreachable through the current type.

Taking Sign later therefore means changing payload_hash to a payload, which is a breaking port change. That is worth recording here so it is a planned cost rather than a surprise, and it is a second reason not to take the branch speculatively: the type would have to change before the capability was ever exercised.

What is unaffected

Everything downstream of the existing shape stands: the digest-over-the-JWS-string choice, the declared mimetype, and the extensionless filename are all consequences of Wrap and remain correct under it.

Suggested disposition: close as answered — Wrap, with the payload-vs-digest break noted as a known future cost, and reopen only if a JAdES-capable provider is contracted.