8. Quality Passport

This section is normative.

A Quality Passport is an in-toto attestation that collects every record behind a release, so that a third party can verify it without access to internal tools.

8.1 Statement

A passport MUST be an in-toto Statement v1. Its subject lists the released artifacts with their digests. Its predicateType identifies the OIS passport predicate.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "customer-portal", "digest": { "sha256": "<release digest>" } }
  ],
  "predicateType": "https://ois.example/passport/v0.1",
  "predicate": { }
}

The predicate type URI above is a placeholder. The final URI is assigned when the project domain is chosen (Appendix C).

8.2 Predicate

Field	Type	Req.	Description
ois	string	REQUIRED	Specification version, "0.1".
release	object	REQUIRED	name and version of the release, optional location (URI).
intents	array of Ref	REQUIRED	Versioned references to the intents the release delivers.
scope	array of Ref	OPTIONAL	Criterion references the release is meant to deliver. When present, coverage methods count only these; when absent, all criteria of the listed intents.
records	array of records	REQUIRED	Records the passport relies on, embedded. MAY be empty when bundles carries them.
bundles	array of object	OPTIONAL	External bundles whose records count as embedded: each with location (URI) and digest. Keeps large passports small.
assessments	array of Measurement	OPTIONAL	Summary values such as intent coverage, each with its method.
issuedBy	Ref	REQUIRED	Reference to the actor that assembled the passport.
issuedAt	timestamp	REQUIRED	When the passport was assembled.

Rules:

• A passport MUST be self-contained: every reference to an intent, actor, artifact, evidence or decision record MUST resolve to a record inside records or inside a bundle listed in bundles. Consumers MUST verify the digest of each listed bundle before using its records.
• records, or a bundle listed in bundles, MUST contain at least one decision with gate release whose subject is the release, with outcome approved or passed.
• For every listed intent, records MUST contain the approved intent version and its intent-approval decision.

records SHOULD also include every current finding that references a listed intent, so that a passport does not hide known defects (R13).

8.3 Signing

• Passports SHOULD be wrapped in a DSSE envelope with payload type application/vnd.in-toto+json and signed. Level 3 conformance requires this (section 11).
• Bundles MAY be signed the same way, with payload type application/vnd.ois+json.
• Sigstore keyless signing is RECOMMENDED where public verification matters. Organizations MAY use their own keys instead.
• Consumers MUST verify the signature before relying on a signed passport, and MUST check that the subject digests match the released artifacts.
• A passport MAY be stored next to SLSA provenance for the same release. The two complement each other: SLSA states how it was built, the passport states that it does what was required.

A signature is attributed to an actor through that actor’s identity. Consumers MUST treat a bundle or passport as signed by an actor only when the signer identity in the DSSE envelope or its certificate matches the actor’s identity.

Level 3 producers SHOULD also record each signature in a transparency log such as Sigstore Rekor. The log gives an independent time and order for every signature, so observedAt and decidedAt no longer rest on the producer’s own clock.