checkId: doctor.evidence.timestamp.eidas.trust-list-fresh family: doctor-check/v1 service: evidence-web scope: installation severity: warning tags: [timestamping, eidas, trusted-list, freshness, evidence]
Trusted List Fresh
Stella Ops is self-hosted software. It does not issue electronic time stamps or provide any qualified trust service. This deployment performs local verification using operator-supplied evidence. Unless an approved jurisdiction-, provider-, service-, and deployment-specific claim profile applies, qualified status is not determined.
Checks that the trusted-list material in use is signature-verified, not past its declared next update, and inside its age budget. Signature-SHAPED XML is not verification: an unverified pack is a hard failure, not a warning about its age. Default severity when it fails: warning. Installation-scoped: one result per estate, served on the Evidence doctor path and probed on the worker schedule trust-list-refresh (daily).
What it measures
- Critical when the pack is not signature-verified or is past its
nextUpdate. - Critical when older than
TrustListCriticalAge(default 7 days); warning aboveTrustListWarnAge(default 3 days).
The check never reports a pass for a value it does not have. When its source cannot be read it reports unhealthy with the message Source unavailable (<reason>): <detail>. No verdict can be reported. and the evidence keys source.state=unavailable, source.reason (one of source-not-configured, source-configuration-invalid, unavailable-by-sealed-policy, source-material-invalid, source-read-failed) and source.detail.
Evidence keys
trustList.signatureVerifiedtrustList.issuedAttrustList.nextUpdatetrustList.ageDaystrustList.digesttrustList.provenancetrustList.mode
Every value is a bounded measurement or pointer; no token bytes, trust material or credentials appear in evidence.
Common causes
- No trusted-list source is wired (current state everywhere).
- Once wired: a stale or unverifiable pack.
Configuration
Interpreting an ETSI trusted list needs the Cryptography eIDAS plugin, and the plugin ABI exposes no trusted-list contract to Evidence yet; this check therefore reports unavailable with reason source-not-configured on every estate today, even when the OfflineKit bundle carries a trust-list part. Transporting the material and interpreting it are separate problems.
Thresholds live in Evidence__TimestampAssurance__Policy__* and default to the values the retired Doctor plugin used (carried verbatim so a cadence or threshold change is always a visible edit).
How to verify
The 17 installation checks are served by evidence-web on the shared doctor-check/v1 path and need the ops.health scope. Probe the service DIRECTLY from inside the estate network: the gateway’s unprefixed /doctor/evidence/checks resolves to whichever service registered that template first, not to Evidence.
curl -sS -H "Authorization: Bearer $OPS_HEALTH_TOKEN" \
http://evidence-web.stella-ops.local:8080/doctor/evidence/checks \
| jq '.checks[] | select(.checkId == "doctor.evidence.timestamp.eidas.trust-list-fresh")'
Once the Evidence doctor registration is activated (it is off by default in a sealed estate), the same result is also visible through the Platform doctor aggregator under the evidence service.
Related checks
- Qualified Status (Claim-Gated) (
doctor.evidence.timestamp.eidas.qualified-status) - Qualified Status Change (
doctor.evidence.timestamp.eidas.status-change) - TSA Trust Anchor Expiry (
doctor.evidence.timestamp.tsa.root-expiry)
This is a local evidentiary classification of the token and issuing service at the stated time. It is not the output of a qualified validation or qualified preservation service and does not determine the legal effect of the underlying release, document, or transaction.
