The problem
SealVerification reports the outcome as valid: bool. The validation model AdES
implementations actually follow is three-valued: a seal passes, fails, or is
indeterminate — the check could not be completed because material it needs was
unavailable. Revocation data unreachable, a timestamp not yet corroborated, a trust
anchor unresolvable at the moment of asking.
Indeterminate is not an edge case. It is the ordinary answer whenever a validator is
asked about a seal whose supporting material has to be fetched, and it is the answer
carrying the most operational meaning: ask again later, not reject this passport.
A boolean cannot carry it, and both collapses are wrong in a way that matters:
indeterminate → false reports a sound seal as invalid, and by extension a
passport as non-compliant when it is not.indeterminate → true claims a check that never completed.
The second thing the type cannot say
valid: true is also silent about what was checked. Verifying that a signature is
consistent with the certificate it carries, and validating that the certificate
chains to a Trusted List with revocation and timestamp corroborated, are different
claims of very different weight. Today they are indistinguishable in the result.
That matters most for an implementation that legitimately can only make the first
claim — a development signer holding its own key, where a cryptographic check is
the whole truth about the artefact. It has no way to say so without reporting the
same valid: true that a full validation would.
What already exists
SealVerification { valid, placeholder }. placeholder correctly separates "this is
a synthetic envelope" from the verdict itself, and that split should survive whatever
replaces the boolean.
Scope
- A verdict that expresses passed / failed / indeterminate, with a reason attached to
the last.
- A statement of what was actually checked, so a signature check is distinguishable
from a full validation.
- No provider vocabulary, and no assumption that the party calling
verify is the
party that produced the seal — for a qualified seal those should usually differ,
since a verdict is worth what the independence of its issuer is worth.
Why now rather than later
SealVerification has two fields, is constructed in exactly two places, and nothing
anywhere reads valid. The break is close to free today. It stops being free the
moment a verdict is rendered into a served view or persisted — and a validation
result that was recorded wrongly is worse than one that was merely unavailable,
because the record outlives the condition that produced it.
The three status indications should be checked against the ETSI validation standard
(EN 319 102-1) before their names are written into the type. This issue describes the
shape, not the vocabulary.
Related: #125 (the port must not assume a single trust provider).
The problem
SealVerificationreports the outcome asvalid: bool. The validation model AdESimplementations actually follow is three-valued: a seal passes, fails, or is
indeterminate — the check could not be completed because material it needs was
unavailable. Revocation data unreachable, a timestamp not yet corroborated, a trust
anchor unresolvable at the moment of asking.
Indeterminate is not an edge case. It is the ordinary answer whenever a validator is
asked about a seal whose supporting material has to be fetched, and it is the answer
carrying the most operational meaning: ask again later, not reject this passport.
A boolean cannot carry it, and both collapses are wrong in a way that matters:
indeterminate → falsereports a sound seal as invalid, and by extension apassport as non-compliant when it is not.
indeterminate → trueclaims a check that never completed.The second thing the type cannot say
valid: trueis also silent about what was checked. Verifying that a signature isconsistent with the certificate it carries, and validating that the certificate
chains to a Trusted List with revocation and timestamp corroborated, are different
claims of very different weight. Today they are indistinguishable in the result.
That matters most for an implementation that legitimately can only make the first
claim — a development signer holding its own key, where a cryptographic check is
the whole truth about the artefact. It has no way to say so without reporting the
same
valid: truethat a full validation would.What already exists
SealVerification { valid, placeholder }.placeholdercorrectly separates "this isa synthetic envelope" from the verdict itself, and that split should survive whatever
replaces the boolean.
Scope
the last.
from a full validation.
verifyis theparty that produced the seal — for a qualified seal those should usually differ,
since a verdict is worth what the independence of its issuer is worth.
Why now rather than later
SealVerificationhas two fields, is constructed in exactly two places, and nothinganywhere reads
valid. The break is close to free today. It stops being free themoment a verdict is rendered into a served view or persisted — and a validation
result that was recorded wrongly is worse than one that was merely unavailable,
because the record outlives the condition that produced it.
The three status indications should be checked against the ETSI validation standard
(EN 319 102-1) before their names are written into the type. This issue describes the
shape, not the vocabulary.
Related: #125 (the port must not assume a single trust provider).