Skip to content

Latest commit

 

History

History
45 lines (33 loc) · 1.87 KB

README.md

File metadata and controls

45 lines (33 loc) · 1.87 KB
Raw

in-toto Attestation Framework Spec

Latest version: v1.0

An in-toto attestation is authenticated metadata about one or more software artifacts1. The intended consumers are automated policy engines, such as in-toto-verify and Binary Authorization.

It has four layers that are independent but designed to work together:

  • Predicate: Contains arbitrary metadata about a subject artifact, with a type-specific schema.
  • Statement: Binds the attestation to a particular subject and unambiguously identifies the types of the predicate.
  • Envelope: Handles authentication and serialization.
  • Bundle: Defines a method of grouping multiple attestations together.

The following diagram visualises the relationships between the envelope, statement and predicate layers.

Relationships between the envelope, statement and predicate layers

The source of this diagram can be found here.

The validation model provides pseudocode showing how these layers fit together. See the documentation for more background and examples.

Keywords

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in all documents under this specification are to be interpreted as described in RFC 2119.

Footnotes

  1. This is compatible with the SLSA Attestation Model. ↩