Occurrence that represents a single “attestation”. The authenticity of an
attestation can be verified using the attached signature. If the verifier
trusts the public key of the signer, then verifying the signature is
sufficient to establish trust. In this circumstance, the authority to which
this attestation is attached is primarily useful for look-up (how to find
this attestation if you already know the authority and artifact to be
verified) and intent (which authority was this attestation intended to sign
for).
Note kind that represents a logical attestation “role” or “authority”. For
example, an organization might have one Authority for “QA” and one for
“build”. This note is intended to act strictly as a grouping mechanism for
the attached occurrences (Attestations). This grouping mechanism also
provides a security boundary, since IAM ACLs gate the ability for a principle
to attach an occurrence to a given note. It also provides a single point of
lookup to find all attached attestation occurrences, even if they don’t all
live in the same project.
Details of an attestation occurrence.
An attestation wrapper that uses the Grafeas Signature message.
This attestation must define the serialized_payload that the signatures
verify and any metadata necessary to interpret that plaintext. The
signatures should always be over the serialized_payload bytestring.
An attestation wrapper with a PGP-compatible signature. This message only
supports ATTACHED signatures, where the payload that is signed is included
alongside the signature itself in the same file.