Operator attestation signatures — what verification would require
Status: design note, nothing implemented. The runtime refuses a signed attestation today (
EidasOperatorAttestationStatus.UnsupportedSignature), which is the disposition counsel’s 2026-09-15 reply §4.1 required while verification does not exist: “Do not silently treat a present but unvalidated signature as assurance. Until verification is implemented, remove the operative signature option or reject unsupported signed attestations.” Owner: Cryptography + Documentation author. Tracked as:SPRINT_20260825_016LRS-15. Prompted by: the owner’s instruction (2026-09-15) to plan the signature work rather than only close the hole.
Why this is a plan and not a feature
Counsel imposed no requirement to verify signatures at all, and said so twice. §4.1: “No blanket requirement for a qualified electronic signature or a particular cryptographic algorithm should be imposed on this runtime file, provided the binding customer acceptance is reliably established elsewhere”, and “No particular algorithm or certificate chain is required merely by the contractual role of this attestation.”
So signature verification is optional capability, not compliance debt. Its value is operational — it would let an operator prove the file was authored by someone it authorised, rather than merely present at a path — and the recommended model is explicitly the other way round:
| Role | Artefact | Counsel §4.1 |
|---|---|---|
| Primary contractual record | the attributable acceptance (checkout, signed order, agreed process) | “an attributable acceptance by an authorised representative” |
| Operational declaration | this attestation file | “an operational declaration linked to that record” |
And the warning that decides the design: “A locally editable file that says ‘I am authorised’ and repeats a known Agreement hash should not, by itself, be treated as conclusive evidence that the organisation contracted with the Licensor”, plus “do not equate a file remaining solely in the customer’s deployment with an acceptance received through the agreed contracting channel.”
A verified signature does not change either sentence. It proves a key signed some bytes; it does not prove the signer could bind the organisation. Anyone implementing this should understand they are adding integrity and attribution to a local declaration, not manufacturing contractual proof.
What has to be settled before any code
Counsel: “Where signature verification is implemented, engineering should specify the accepted algorithms, key-to-signatory binding and validation rules.” Those three, and four more that fall out of this runtime’s own constraints:
1. Accepted algorithms
A closed allow-list, fail-closed on anything else — never “whatever the file names”. The attestation is not a qualified signature and must not imply one: eIDAS gives qualified electronic signatures a specific equivalence to handwritten signatures, and “an ordinary cryptographic signature does not become ‘qualified’ merely because it uses a strong algorithm”. Whatever is chosen, the resulting claim state wording must not drift toward qualified-signature language — the representation boundary tests exist to catch exactly that.
2. Key-to-signatory binding — the hard part
Verifying bytes is trivial; binding a key to a person who could bind the operator is not. The options differ in what they actually prove:
- Operator-supplied public key at a configured path. Proves continuity (same key as last time), proves nothing about authority. Cheapest, and honest if described that way.
- Certificate chained to a trust anchor the operator configures. Proves the chain, moves the authority question to whoever issued the certificate.
- Certificate chained to a QTSP-issued identity. The strongest, and it drags the qualified-status vocabulary into a file counsel deliberately kept outside it — needs its own review before being chosen.
Whichever is picked, the binding must be stated in the claim state, not just in code: a state that says “signature verified” without saying against what is the kind of unqualified assurance the representation boundary forbids.
3. Validation rules
Canonicalisation (which bytes are signed — the file cannot sign itself, so the signature block must be excluded in a defined way), timestamp and expiry handling, revocation checking if certificates are used, and behaviour on a verification error as distinct from a verification failure. Each needs its own fail-closed path and its own named not-claimed reason, on the pattern of the five that exist.
4. Air-gap
Revocation checking that reaches the network cannot be a precondition in an offline-first product. Either the model avoids revocation, or the operator supplies revocation material the way they already supply the trust pack — and then that material needs its own freshness rule, which is a second gate, not a footnote.
5. Migration, and the only rule that is already decided
The current behaviour is refusal, so shipping verification relaxes a gate. That inverts the usual risk: a file refused today would be accepted tomorrow. Whoever implements it must show that an attestation accepted by the new path would also have satisfied the old unsigned model — otherwise the change quietly widens what produces a positive state.
Already decided (counsel §4.5, implemented): the schema version is the attestation schema version only and confers no permission to accept future schemas. Adding a verified-signature shape is a schema change and therefore a version bump, with the unsupported-version refusal doing its job in the meantime.
6. What it must not become
The attestation stays operator-authored and operator-controlled. Stella Ops never signs it — that asymmetry is the whole point of the control, and it is what keeps the qualified-service representation on the operator’s side of the boundary. A verification feature that ended with Stella Ops issuing keys, or vouching for signatories, would dissolve the control it was meant to strengthen.
The cheaper alternative, stated honestly
Counsel’s model does not need this at all. If the goal is attribution, the effective lever is the one LRS-12 builds: an acceptance record held by the Licensor, carrying the signatory’s name, title, authority declaration, signing context and timestamp — “the Licensor must be able to produce this evidence independently of continued access to a merchant dashboard”. That record proves who bound the organisation. A signature on a local file does not, however good the cryptography.
Recommendation: do not implement signature verification until an operator asks for it with a concrete reason. The refusal that ships today is complete and correct on counsel’s own terms, and the honest form of “we support signatures” is expensive to reach.