Summary

  • RFC 9943 defines SCITT structures through which an Issuer signs a statement about an artifact, a Transparency Service registers it under a policy, and a Receipt proves bounded properties of that registration.
  • The architecture makes provenance and history auditable; it does not make the statement accurate, force full issuer participation, rank the adequacy of a registration policy, or replace a Relying Party's own decision.

The useful unit of evidence is smaller than the word “trust” suggests. SCITT — Supply Chain Integrity, Transparency, and Trust — starts with a signed statement about an artifact. The issuer identifies itself in protected COSE material and binds the statement to an artifact subject. A transparency service, or TS, performs required checks, applies its registration policy, appends the accepted statement to a verifiable data structure, and returns a COSE Receipt. When that receipt is attached, the result is a Transparent Statement.

That is a serious capability: an issuer cannot quietly replace the recorded statement without leaving an inconsistent history, and an auditor can inspect the service's sequence.

But each component has a bounded speaker. The issuer speaks for the claim it signed. The TS speaks for what it registered under its own published policy and for the verifiable structure that supports its receipt. The auditor checks correctness and consistency. The relying party decides what evidence is sufficient for its own deployment, procurement, access, release, or continuity decision. A receipt becomes dangerous when one of those voices is mistaken for all of them.

The registration path makes the separation concrete. RFC 9943 requires a TS to verify the signature, bind an issuer identity in protected headers, maintain trust anchors, authenticate signed statements, and expose registration policies. Yet the document says the scope of additional checks — including no additional checks — is implementation-specific. It also leaves client authentication and authorization outside the architecture. A TS can therefore give useful, cryptographically verifiable evidence that a particular signed statement met its stated gate.

It does not thereby certify every proposition inside the payload, every relationship around the issuer, or every criterion a relying party may need.

This distinction matters even when the policy is strict. A registration policy can require a known key, a protected issuer and subject, an expected media type, or particular non-opaque attributes. Those checks establish a reproducible admission rule for the ledger. They do not establish that an SBOM is exhaustive, that a vulnerability statement remains current, that a build process was safe, or that a supplier revealed every adverse fact. A well-designed transparency service narrows ambiguity about its own act. It should not be asked to impersonate the issuer's truthfulness or the relying party's judgment.

RFC 9943 says this directly in its security analysis. An issuer can make a false statement intentionally or by mistake; registration proves only that the statement was produced by that issuer. A later statement from the same issuer may supersede it. Other issuers may publish corrected information. Nor must issuers submit every statement they issue: they can refuse registration or selectively participate. The architecture gives a relying party a better record with which to confront those limits. It does not make omission disappear.

The ordering issue is another useful brake. A verifiable data structure records a sequence, but a relying party cannot assume that ledger order equals issuance order unless the TS's registration policy says so. An inclusion proof tells a reader that a statement occupied a specified place in a particular logged structure. It is not, by itself, a complete chronology of the artifact, a measure of the statement's importance, or proof that no relevant event happened elsewhere. Treating a proof as a universal timeline adds claims the protocol did not make.

SCITT therefore asks for a disciplined verification conversation. First, verify the issuer's statement and identify exactly what its protected headers and payload say. Second, verify the TS receipt against a key and identity the relying party actually trusts. Third, inspect the TS's registration policy, trust-anchor model, disclosure posture, and ability to expose consistency evidence. Finally, apply a local policy that can take the envelope, receipt, payload and local state as inputs. RFC 9943 explicitly permits that final local validation after cryptographic checks. It is not an embarrassing exception.

It is where accountable judgment belongs.

Heng Lu's minimum-initial-specification argument helps explain the virtue of that boundary. A shared mechanism becomes durable when it makes a narrow proposition checkable without pretending to settle every future, local decision. SCITT's receipt can travel between institutions precisely because it says something bounded about a logged signed statement. If the receipt silently became an approval, a warranty, a procurement authorization or a release verdict, every user would inherit someone else's unannounced policy.

The running-code principle supplies the same warning: a successful verification run demonstrates that named verification machinery ran over named material. It does not turn the machinery into the owner of a downstream consequence.