Two gaps assessed during the eID Easy sealing work (#57) and deliberately not built there. Neither blocks the provider sandbox test.
1. SealedEnvelope.signing_cert_ref is always None
The certificate that produced a seal sits inside the detached CAdES (.p7s), and the adapter does not parse CMS, so which certificate sealed a given passport is not answerable from the passport row. An auditor asking "which qualified certificate signed this, and was it on the Trusted List at the time?" currently has to be handed the .p7s and parse it themselves.
Why it was not built in #57. We cannot validate the certificate chain regardless — that is the independent AdES validator's job, and the whole adapter is built around not claiming checks it did not perform. Parsing a certificate out to populate a convenience field risks producing something that reads as verification while verifying nothing. That trade needs deciding deliberately, not in passing.
What it would take. A CMS/ASN.1 dependency (cms + x509-cert from RustCrypto), extraction of the signer info, and a decision on what signing_cert_ref should actually hold — issuer+serial, a SKI, or a fingerprint. Whatever is chosen must be labelled as reported by the seal, not as verified.
Worth revisiting when: a pilot or auditor asks the question, or the evidence dossier needs to be self-describing without a separate validator pass.
2. No batching — one digest per request
eID Easy's Direct e-Sealing accepts 1–30 files per request; the adapter sends one. At item-level issuance (a battery production line runs to tens of thousands of passports a month) that is up to 30× more HTTP requests than necessary.
Why it was not built in #57. SealPort::seal takes one request, so batching means a core port change (dpp-core), not just an engine one. It saves requests rather than per-seal cost — billing is per seal — and until the provider's rate limits are known we cannot tell whether the request count is a problem at all. Their docs publish no limits and support has not answered. Optimising an unmeasured cost at a volume we do not yet have is the wrong order.
What it would take. A batching method on SealPort in dpp-core, a drain restructure to group due rows, and per-row outcome mapping so one bad digest in a batch does not fail the other 29.
Worth revisiting when: the sandbox reveals a rate limit, or a pilot's issuance granularity makes the request volume real.
Sequencing
Both should wait for the provider sandbox test, which is blocked on eID Easy enabling test e-seal credentials. The first real seal will inform both — what the returned .p7s actually contains, and what their rate limits actually are.
Two gaps assessed during the eID Easy sealing work (#57) and deliberately not built there. Neither blocks the provider sandbox test.
1.
SealedEnvelope.signing_cert_refis alwaysNoneThe certificate that produced a seal sits inside the detached CAdES (
.p7s), and the adapter does not parse CMS, so which certificate sealed a given passport is not answerable from the passport row. An auditor asking "which qualified certificate signed this, and was it on the Trusted List at the time?" currently has to be handed the.p7sand parse it themselves.Why it was not built in #57. We cannot validate the certificate chain regardless — that is the independent AdES validator's job, and the whole adapter is built around not claiming checks it did not perform. Parsing a certificate out to populate a convenience field risks producing something that reads as verification while verifying nothing. That trade needs deciding deliberately, not in passing.
What it would take. A CMS/ASN.1 dependency (
cms+x509-certfrom RustCrypto), extraction of the signer info, and a decision on whatsigning_cert_refshould actually hold — issuer+serial, a SKI, or a fingerprint. Whatever is chosen must be labelled as reported by the seal, not as verified.Worth revisiting when: a pilot or auditor asks the question, or the evidence dossier needs to be self-describing without a separate validator pass.
2. No batching — one digest per request
eID Easy's Direct e-Sealing accepts 1–30 files per request; the adapter sends one. At item-level issuance (a battery production line runs to tens of thousands of passports a month) that is up to 30× more HTTP requests than necessary.
Why it was not built in #57.
SealPort::sealtakes one request, so batching means a core port change (dpp-core), not just an engine one. It saves requests rather than per-seal cost — billing is per seal — and until the provider's rate limits are known we cannot tell whether the request count is a problem at all. Their docs publish no limits and support has not answered. Optimising an unmeasured cost at a volume we do not yet have is the wrong order.What it would take. A batching method on
SealPortindpp-core, a drain restructure to group due rows, and per-row outcome mapping so one bad digest in a batch does not fail the other 29.Worth revisiting when: the sandbox reveals a rate limit, or a pilot's issuance granularity makes the request volume real.
Sequencing
Both should wait for the provider sandbox test, which is blocked on eID Easy enabling test e-seal credentials. The first real seal will inform both — what the returned
.p7sactually contains, and what their rate limits actually are.