Persist and expose the seal conformance level (blocked on the dpp-domain repin)

[LKSNDRTMLKV]

SealedEnvelope in dpp-domain now carries conformance_level: Option<SealConformanceLevel>, serialised as conformanceLevel. The engine cannot use it until it repins dpp-domain past the release that contains it (currently pinned at 0.19.0, from crates.io, with no [patch]).

Blocked on that repin. Filing now so the work is not rediscovered.

Why the field exists

SealConformanceLevel documents why the level is on the request: a BaselineB seal stops verifying when its signing certificate expires, ESPR retention outlives certificate lifetimes comfortably, the seal is bought once, and the passport it covers is retention-locked — so the choice cannot be corrected afterwards.

All of that is about the stored seal, and the stored seal did not record it. A node that runs the local backend at B, then a hosted provider at T, then LT, leaves three populations of passport that are indistinguishable in storage — and the ones that will stop verifying first are the ones nobody can identify.

What to change

1. crates/dpp-seal/src/local/sealer.rs — LocalIdentity::seal sets conformance_level: Some(SealConformanceLevel::BaselineB). It advertises BaselineB only, and sign_detached sets unsigned_attrs: None, so BaselineB is what the bytes are. Not req.conformance_level: the boot gate already refuses a mismatch, so echoing would only launder a bug.
2. crates/dpp-seal/src/eideasy/client.rs — set it from level_for_profile(&self.config.signature_profile), the same source capabilities() uses. That is the level the client was configured to ask for, which is the honest claim available without reading the returned CMS. Reading it out of the bytes is #TODO-DETECT.
3. crates/dpp-seal/src/adapter.rs and src/ghost.rs — the ghost echoes the request, matching GhostSeal in dpp-domain.
4. api/components/schemas/passport/SealedEnvelope.yaml — add an optional conformanceLevel referencing a new SealConformanceLevel.yaml enum (baseline-b, baseline-t, baseline-lt, baseline-lta; kebab-case, matching the serde representation). Optional in both directions: an envelope written before the field reads back absent, and an absent level must be omitted, never serialised as null — a "conformanceLevel": null appearing on a stored passport would be a content change on a retention-locked document.
5. crates/dpp-vault/src/handlers/seal.rs — add conformance_level to SealResponse, documented in the register the rest of that struct already uses: a record of what was requested, the same standing as sealedPayloadHash, not proof of what arrived. Mirror it in api/components/schemas/seals/SealResponse.yaml.
6. ops/pg/ — no migration needed. The seal lives inside passport.doc, seal is already on the retention guard's mutable_keys, and the field is additive within that JSON.

Tests worth having

• A seal drained end to end carries the level the backend advertises.
• A stored envelope predating the field still deserialises, with the level absent.
• openapi_contract.rs covers the new property in both directions.

The dpp-domain conformance kit already gained rule 6 (seal.misrecorded_level), which fails an adapter whose envelope records a level disagreeing with the request it answered. adapter.rs runs that kit, so an implementation mistake here shows up as a kit failure rather than as a wrong record in production.

[LKSNDRTMLKV]

The blocker is narrower than "wait for a release"

just core-local copies .cargo/config.toml.example into place, which patches every dpp-* crate to the sibling ../dpp-core working tree. With it active the new field is visible immediately — no publish, no version bump. So this issue can be built and tested as soon as the core-side change is merged; only merging it here has to wait for the pin to move, because CI and release builds deliberately have no .cargo/config.toml and always resolve the published versions.

Run just core-published to drop the override again.

⚠️ The trap in the middle of the sequence

From .cargo/config.toml.example, and it bites exactly during this handover:

a [patch] only applies when the local crate's version satisfies the requirement in Cargo.toml. If you bump dpp-core's version ahead of the published one, update Cargo.toml to match or Cargo will ignore the patch.

Right now the two line up — core's workspace version is 0.19.0 and this workspace requires dpp-domain = "0.19.0" — so the patch applies. The moment core's version is bumped to 0.20.0 for the release, "0.19.0" stops being satisfied by the local path and Cargo silently ignores the patch, falling back to the registry 0.19.0, which does not have the field.

The symptom is a compile error saying the field does not exist, with the override file sitting right there apparently active. That reads as "the core change was not merged", which is the wrong diagnosis and costs an hour. It is a version-requirement mismatch, and the fix is step 4 below.

Sequence

1. Merge the core-side change.
2. Now: just core-local, build this issue's work against it. Fully unblocked for development.
3. Cut the core release. It carries several queued breaking changes already, so this rides an existing release rather than needing one of its own.
4. Bump dpp-domain — and its siblings together, since the pins move in lockstep — in [workspace.dependencies]. Do this in the same commit as the version bump lands, or step 2's override goes quietly dead.
5. Merge this.

Already done, and not blocked

The detection half of this work shipped separately, because it reads the returned CMS rather than the new field and needed nothing from core: dpp_seal::cades::evidenced_level, plus a drain-time downgrade check and a seal_downgraded_total counter. So the silent downgrade risk is already covered; what remains here is persisting and exposing the level that was requested, so the record and the bytes can be compared.

One finding from that work is worth carrying into this one. The two standards disagree about where an LT seal's revocation material lives — EN 319 122-1 puts it in SignedData.crls and forbids the revocation-values attribute at that level, while ETSI TS 103 173 (the profile CID (EU) 2015/1506 actually names) puts it in that attribute. Anything comparing requested against evidenced must go through evidenced_level, which accepts both, rather than re-deriving the check.

[LKSNDRTMLKV]

Done in #312 (merged to main). The dpp-domain repin this was blocked on is in.

Persisted. Both seal backends set SealedEnvelope::conformance_level, and both set it to the level that was requested rather than the level the bytes turned out to carry. That is what the field's own documentation specifies — "a record of what was asked for, not proof of what arrived" — and core's conformance kit enforces it: seal.misrecorded_level fails an envelope whose stored level disagrees with the request.

That distinction mattered in practice. The trusted-list branch had independently written the other behaviour (recording what sign_detached actually emits), and the two met as a merge conflict during the revival in #316. Resolved in favour of the request, with the concern behind the other version preserved in the comment: echoing a request could launder a broken can_produce guard, and what catches that is cades::evidenced_level, read independently by the drain, which alarms on the disagreement rather than letting either side vouch for itself.

Exposed. conformanceLevel is on the SealedEnvelope schema, with a new SealConformanceLevel enum reading ALL off the core type so its fixture cannot drift. Absent means not recorded — an envelope written before the field existed, or a seal restored from a backup — and never that the level was low.

Both successful backend tests now assert it, which they did not when this was filed: the local sealer against BaselineB and the eID Easy adapter against BaselineT.