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 lookup (how to find this attestation if you already know the authority and artifact to be verified) and intent (for which authority this attestation was intended to sign.
Fields
serialized_payload
bytes
Required. The serialized payload that is verified by one or more signatures.
One or more signatures over serialized_payload. Verifier implementations should consider this attestation message verified if at least one signature verifies serialized_payload. See Signature in common.proto for more details on signature structure and verification.
One or more JWTs encoding a self-contained attestation. Each JWT encodes the payload that it verifies within the JWT itself. Verifier implementation SHOULD ignore the serialized_payload field when verifying these JWTs. If only JWTs are present on this AttestationOccurrence, then the serialized_payload SHOULD be left empty. Each JWT SHOULD encode a claim specific to the resource_uri of this Occurrence, but this is not validated by Grafeas metadata API implementations. The JWT itself is opaque to Grafeas.
Verifiers (e.g. Kritis implementations) MUST verify signatures with respect to the trust anchors defined in policy (e.g. a Kritis policy). Typically this means that the verifier has been configured with a map from public_key_id to public key material (and any required parameters, e.g. signing algorithm).
In particular, verification implementations MUST NOT treat the signature public_key_id as anything more than a key lookup hint. The public_key_id DOES NOT validate or authenticate a public key; it only provides a mechanism for quickly selecting a public key ALREADY CONFIGURED on the verifier through a trusted channel. Verification implementations MUST reject signatures in any of the following circumstances: * The public_key_id is not recognized by the verifier. * The public key that public_key_id refers to does not verify the signature with respect to the payload.
The signature contents SHOULD NOT be "attached" (where the payload is included with the serialized signature bytes). Verifiers MUST ignore any "attached" payload and only verify signatures with respect to explicitly provided payload (e.g. a payload field on the proto message that holds this Signature, or the canonical serialization of the proto message that holds this signature).
Fields
signature
bytes
The content of the signature, an opaque bytestring. The payload that this signature verifies MUST be unambiguously provided with the Signature during verification. A wrapper message might provide the payload explicitly. Alternatively, a message might have a canonical serialization that can always be unambiguously computed to derive the payload.
public_key_id
string
The identifier for the public key that verifies this signature. * The public_key_id is required. * The public_key_id SHOULD be an RFC3986 conformant URI. * When possible, the public_key_id SHOULD be an immutable reference, such as a cryptographic digest.
RFC6920 digest-named SubjectPublicKeyInfo (digest of the DER serialization): * "ni:///sha-256;cD9o9Cq6LG3jD0iKXqEi_vdjJGecm_iXkbqVoScViaU" * "nih:///sha-256;703f68f42aba2c6de30f488a5ea122fef76324679c9bf89791ba95a1271589a5"
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-05-30 UTC."],[[["\u003cp\u003e\u003ccode\u003eAttestationOccurrence\u003c/code\u003e represents a single attestation, verifiable through an attached signature, which is mainly used for lookup and identifying the intended authority.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eAttestationOccurrence\u003c/code\u003e message includes a \u003ccode\u003eserialized_payload\u003c/code\u003e verified by one or more \u003ccode\u003esignatures\u003c/code\u003e, or it can include one or more \u003ccode\u003ejwts\u003c/code\u003e that each encode their own payload within the JWT.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eJwt\u003c/code\u003e messages contain a \u003ccode\u003ecompact_jwt\u003c/code\u003e field, which is a compact encoding of a JWS (JSON Web Signature) as specified in RFC7515.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eSignature\u003c/code\u003e messages contain a \u003ccode\u003esignature\u003c/code\u003e field, an opaque byte string, and a \u003ccode\u003epublic_key_id\u003c/code\u003e that serves as a lookup hint for the verifier's configured public keys, and whose sole use is for this purpose, as it should not be used to validate or authenticate said public key.\u003c/p\u003e\n"],["\u003cp\u003eVerifiers must reject signatures when the public key ID is unrecognized or when the public key does not verify the signature, and verifiers must not consider any attached payload to the signature when verifying.\u003c/p\u003e\n"]]],[],null,["# Package grafeas.v1\n\nIndex\n-----\n\n- [AttestationOccurrence](/binary-authorization/docs/reference/rpc/grafeas.v1#grafeas.v1.AttestationOccurrence) (message)\n- [Jwt](/binary-authorization/docs/reference/rpc/grafeas.v1#grafeas.v1.Jwt) (message)\n- [Signature](/binary-authorization/docs/reference/rpc/grafeas.v1#grafeas.v1.Signature) (message)\n\nAttestationOccurrence\n---------------------\n\nOccurrence 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 lookup (how to find this attestation if you already know the authority and artifact to be verified) and intent (for which authority this attestation was intended to sign.\n\nJwt\n---\n\nSignature\n---------\n\nVerifiers (e.g. Kritis implementations) MUST verify signatures with respect to the trust anchors defined in policy (e.g. a Kritis policy). Typically this means that the verifier has been configured with a map from `public_key_id` to public key material (and any required parameters, e.g. signing algorithm).\n\nIn particular, verification implementations MUST NOT treat the signature `public_key_id` as anything more than a key lookup hint. The `public_key_id` DOES NOT validate or authenticate a public key; it only provides a mechanism for quickly selecting a public key ALREADY CONFIGURED on the verifier through a trusted channel. Verification implementations MUST reject signatures in any of the following circumstances: \\* The `public_key_id` is not recognized by the verifier. \\* The public key that `public_key_id` refers to does not verify the signature with respect to the payload.\n\nThe `signature` contents SHOULD NOT be \"attached\" (where the payload is included with the serialized `signature` bytes). Verifiers MUST ignore any \"attached\" payload and only verify signatures with respect to explicitly provided payload (e.g. a `payload` field on the proto message that holds this Signature, or the canonical serialization of the proto message that holds this signature)."]]
