Request message for ValidationHelperV1.ValidateAttestationOccurrence
.
JSON representation |
---|
{
"attestor": string,
"attestation": {
object ( |
Fields | |
---|---|
attestor |
Required. The resource name of the |
attestation |
Required. An |
occurrenceNote |
Required. The resource name of the [Note][grafeas.v1.Note] to which the containing [Occurrence][grafeas.v1.Occurrence] is associated. |
occurrenceResourceUri |
Required. The URI of the artifact (e.g. container image) that is the subject of the containing [Occurrence][grafeas.v1.Occurrence]. |
AttestationOccurrence
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.
JSON representation |
---|
{ "serializedPayload": string, "signatures": [ { object ( |
Fields | |
---|---|
serializedPayload |
Required. The serialized payload that is verified by one or more A base64-encoded string. |
signatures[] |
One or more signatures over |
jwts[] |
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 |
Signature
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 publicKeyId
to public key material (and any required parameters, e.g. signing algorithm).
In particular, verification implementations MUST NOT treat the signature publicKeyId
as anything more than a key lookup hint. The publicKeyId
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 publicKeyId
is not recognized by the verifier. * The public key that publicKeyId
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).
JSON representation |
---|
{ "signature": string, "publicKeyId": string } |
Fields | |
---|---|
signature |
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. A base64-encoded string. |
publicKeyId |
The identifier for the public key that verifies this signature. * The Examples of valid OpenPGP V4 public key fingerprint: * "openpgp4fpr:74FAF3B861BDA0870C7B6DEF607E48D2A663AEEA" See https://www.iana.org/assignments/uri-schemes/prov/openpgp4fpr for more details on this scheme. RFC6920 digest-named SubjectPublicKeyInfo (digest of the DER serialization): * "ni:///sha-256;cD9o9Cq6LG3jD0iKXqEi_vdjJGecm_iXkbqVoScViaU" * "nih:///sha-256;703f68f42aba2c6de30f488a5ea122fef76324679c9bf89791ba95a1271589a5" |
Jwt
JSON representation |
---|
{ "compactJwt": string } |
Fields | |
---|---|
compactJwt |
The compact encoding of a JWS, which is always three base64 encoded strings joined by periods. For details, see: https://tools.ietf.org/html/rfc7515.html#section-3.1 |