Qualified electronic timestamping, RFC 3161 and the current sandbox boundary
A timestamp can be cryptographically valid without being legally qualified. SiteSealed treats format, signature validation, provider status and legal effect as separate questions so that a sandbox token is never advertised as more than it is.
RFC 3161 defines a technical token, not qualification by itself
RFC 3161 describes a protocol in which a time-stamping authority receives a message imprint and returns a signed token binding that digest to a stated time. The original construction file does not need to be disclosed to the authority: SiteSealed sends the evidence digest. A verifier can inspect the token's message imprint, signed time, signature, signer certificate reference and certificate chain and can compare the imprint with the digest recorded in the proof bundle.
A valid RFC 3161 structure is only one technical layer. Qualification under the EU eIDAS framework depends on the service being a qualified electronic time-stamping service provided by a qualified trust service provider and identified as qualified in the applicable EU Trusted List. A self-signed token, development certificate or sandbox service does not acquire qualified status merely because common cryptographic software accepts its signature.
What the eIDAS presumption covers
Article 41 of Regulation (EU) No 910/2014, as amended, gives a qualified electronic timestamp a presumption of the accuracy of the date and time it indicates and the integrity of the data to which that time is bound. A qualified timestamp issued in one Member State is recognised as qualified in the other Member States. The presumption concerns time and data integrity; it does not certify that a photograph depicts a true event, identify every person shown or prove that a scene was not staged.
The distinction matters in construction disputes. A qualified token can strengthen the proposition that exact data existed by the indicated time and was not changed undetectably afterwards. Other questions remain subject to ordinary evidence: who controlled the device, whether the recorded location was authentic, whether the camera saw a physical scene, whether the work complied with a contract and what legal weight a tribunal gives the complete evidentiary record.
Provider status must be checked, not assumed
EU Member States publish trusted lists describing qualified trust service providers and the qualified services for which they are supervised. Provider identity alone is not enough: the specific service and its status at the relevant time matter. A production implementation therefore needs a documented trust policy that connects the token, signer certificate, service identity, trusted-list status and validation time instead of relying on a brand name or a generic TLS connection.
Long-term validation also requires attention to certificate expiry, revocation information, algorithm strength and preservation of the material needed for later verification. SiteSealed's whitepaper targets durable proofs that outlive the vendor. Reaching that target requires more than obtaining a response from an API; it requires preserving the signed token and its validation context and making the result exportable to the party that may later challenge it.
What SiteSealed validates in the alpha
The active Rail A integration uses Evidency Sandbox. SiteSealed submits only a SHA-256 evidence digest, checks that the returned token binds the same digest, validates the CMS signature and ESSCertIDv2 signer binding, and verifies the certificate path to a sandbox root pinned in the release. These controls detect malformed, substituted or cryptographically invalid responses and keep the operational status from turning green merely because an HTTP request succeeded.
None of those checks converts the sandbox service into a qualified production service. The current token is labelled test-only and not qualified, and it has no qualified eIDAS legal effect. Production qualification, a production trust policy and certificate revocation validation remain explicit gates. The public Ethereum anchor is a separate neutral rail and does not substitute for the statutory presumption of a genuinely qualified timestamp.
How to read the Evidence Report
The Evidence Report identifies the timestamp environment, token state and independent verification results. A sandbox-issued token should be read as evidence that the alpha integration produced and validated a particular test artefact, not as a qualified legal act. The report keeps the ALPHA and NOT QUALIFIED language visible even when the cryptographic checks pass.
The same report separately describes the Ethereum anchor and the record's honest scope. This separation lets an expert agree that a signature, digest or Merkle proof is valid without being forced to accept a broader claim about legal qualification, authorship, sensor origin or factual truth. SiteSealed's design is strongest when each conclusion is no wider than the material that supports it.