The split is prior art; the seam is what these four leave open.
Separating what a party knew first-hand from what it was told is not new. SLSA, RATS, SCITT and NISTIR 8112 each draw that line, and none settles what a cross-provider route does to it: that seam is what these notes offer.
The distinction between what a party knew first-hand and what it copied from somebody else's claim did not start here. Four bodies of work draw it, each read on 12 September 2026.
SLSA draws the line normatively at field level inside one attestation:
externalParameters are "the external interface to the build. In SLSA, these values are
untrusted; they MUST be included in the provenance and MUST be verified downstream", while
internalParameters are set by the platform and "are trusted because the platform is
trusted".[1]
RATS supplies the roles: an Attester is "a role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy".[2] SCITT states the residue: registering a Statement "only proves it was produced by an Issuer".[3]
NISTIR 8112 supplies the part most often got wrong, including in the note that started this work. It does not draw a single line between self-asserted and verified attributes. It defines Pedigree — "description of the attribute value's relationship to the authoritative source of the value" — with the values Authoritative, Sourced, Self-Asserted and Derived, where "Authoritative" means "the attribute's value was acquired directly from the source of authority" and "Self-Asserted" means "the value was provided to the AP directly by the individual with whom the attribute value is associated". Verification is a separate axis, and the document says so: "Self-asserted attributes may also be verified or unverified."[4] Two questions rather than one, which is the better precedent: a delegation record needs both where a field came from and whether anything checked it.
What none of them settles is what a cross-provider route does to that split: the field an operator most wants sits on the far side of the boundary in both documented routes. The seam is what none of the four settles, and it is the contribution offered here — a statement about four documents read on one day, not a search of the literature.
The question these notes work on came out of building a routing switch inside Gateward, a Digital One product. It supplies no evidence here: every quotation above is from a published page a reader can fetch, cited with the date it was read, and the Gateward repository is not public, so nothing in it is a claim a reader can check today. Deliberately absent: prices, plans and tiers, availability, and deployment internals.
References
- SLSA, Provenance, version 1.0, the Model section and the
BuildDefinitionfield table, slsa.dev/spec/v1.0/provenance, read 12 September 2026. - H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan, Remote ATtestation procedureS (RATS) Architecture, RFC 9334, January 2023, §4.1 and §4.2, rfc-editor.org/rfc/rfc9334, read 12 September 2026.
- An Architecture for Trustworthy and Transparent Digital Supply Chains (SCITT), RFC 9943, June 2026, §9.2, rfc-editor.org/rfc/rfc9943, read 12 September 2026.
- NIST, Attribute Metadata: A Proposed Schema for Evaluating Federated Attributes, NISTIR 8112, January 2018, DOI 10.6028/NIST.IR.8112, §3.2.1.1 "Provenance Metadata" — Table 6 and the numbered list of recommended values below it, which give the Pedigree element four: Authoritative, Sourced, Self-Asserted, Derived. "Origin" is a separate element on that same table and a recommended value of the Verifier element at §3.2.1.2, Table 7; the front-matter summary table runs its Values column continuously across rows, which is where the two are run together. nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8112.pdf, read 12 September 2026; the PDF's text was extracted locally in order to read it.