Skip to content

Latest commit

 

History

History

spec

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
predicates
predicates
 
 
v0.1.0
v0.1.0
 
 
v1
v1
 
 
README.md
README.md
 
 
versioning.md
versioning.md
 
 

README.md

in-toto Attestation Framework Spec

Latest version: v1.1

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.

Tagged Releases

The latest tagged release version matches the SemVer MAJOR.MINOR version of the Attestation Framework spec.

Backwards-compatible semantic updates to the spec (except predicates) are indicated through new tagged MINOR version releases. We use new tagged PATCH version releases to indicate updates to predicate specifications and/or backwards-compatible changes to the language bindings.

Examples

  • Attestation Framework tagged release v1.0.2 (PATCH version) incorporates refinements to the predicate specification process, a new predicate type, and a small patch to the Golang language bindings. None of these changes affects the semantics of the core spec. The _type of a Statement is still https://in-toto.io/Statement/v1.

  • Tagged release v1.1.0 (MINOR version) generalizes the semantics of the DigestSet field type to support any type of immutable identifier. This change is backwards comptabile because cryptographic digests are strongly recommended to achieve immutability, so any implementations that only support cryptographic DigestSet still meet the modified semantics. The _type of a Statement is still https://in-toto.io/Statement/v1 but a new entry in the v1 CHANGELOG is added.

  • Tagged release v2.0.0 (MAJOR version) changes the meaning of the predicateType field. A new v2 directory is added to /spec and the _type of a Statement becomes https://in-toto.io/Statement/v2.

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. ↩