What is SCITT?

A Statement contains application-defined information about an artifact or other subject. A Signed Statement adds the issuer's cryptographic signature and protected claims. A Transparency Service applies its registration policy, records an accepted Signed Statement in a verifiable data structure, and returns a receipt. RFC 9943 calls the Signed Statement plus its receipt a Transparent Statement.

The artifacts answer different questions. The issuer signature shows whether the statement verifies under a trusted issuer key. The receipt shows whether that exact Signed Statement was registered in one Transparency Service state. Neither mechanism proves that the underlying claim is factually correct.

A format 2 verification record stores exact RFC 8785 canonical JSON bytes and a recomputable SHA-256 seal. When a record has a SCITT Signed Statement, an RFC 9995 Hash Envelope commits to that same evidence digest and media type. The RFC 9943 COSE_Sign1 object binds federal.contractors as issuer, the opaque record URL as subject, an SPKI-derived key id, PS256, and an issuer-asserted issuance time.

New production statements also receive a DigiCert RFC 3161 timestamp under RFC 9921 COSE-then-Timestamp before the record transaction commits. The request sends only the SHA-256 imprint of the CBOR-encoded signature field and protocol metadata. The bare .scitt statement stays unchanged. The bundle carries the timestamped statement and all retained verification artifacts. Signing or timestamp failure prevents production record creation. Legacy format 1 and earlier unsigned or untimestamped format 2 records keep their original verification rules.

The browser and command-line verifier report each assurance layer separately. A valid issuer signature cannot turn an unavailable source or matching check into a passing result.

New production records carry an independent RFC 3161 timestamp, but no independent Transparency Service receipt. A timestamped Signed Statement is not a Transparent Statement. The timestamp proves the issuer signature existed no later than the Timestamp Authority's time. It does not prove the check execution time.

A future receipt would be stored as a separate attachment that identifies the exact Signed Statement it covers. It would not rewrite the evidence bytes, issuer signature, timestamp, or an earlier receipt.

An issuer signature can authenticate federal.contractors as issuer of exact evidence bytes under a trusted key. Its independent timestamp can establish that the signature existed no later than the Timestamp Authority's time. Neither proves that SAM.gov data was correct, that a matching algorithm was applied correctly, that a person identified the right party, that the check ran at the independent time, or that a transaction satisfied a legal requirement.

A matching digest connects evidence objects but does not transfer trust between them. federal.contractors therefore keeps source completeness, identity basis, matching result, issuer signature, independent timestamp, and any future transparency receipt as separate facts. The application reports no active exclusion record matched, a potential match, or matched this UEI. It does not return a generic compliant or verified status.

The permanent record page exposes the evidence JSON, bare .scitt statement, offline bundle, and a browser verification control. The browser uses the same verifier core as the command-line tool. Timestamped bundles include the RFC 3161 request and response, RFC 9921 timestamped statement, certificate trust anchor, and retained revocation lists.

For long-term offline verification, fetch issuer-key history separately from the bundle and retain a copy obtained through a trusted channel. Do not use the key-history copy inside the bundle as its own trust anchor, because a replacement bundle could otherwise appoint a replacement issuer key.