---
title: "POST /v1/{+attestor}:validateAttestationOccurrence"
method: POST
path: "/v1/{+attestor}:validateAttestationOccurrence"
tags: ["projects"]
---

# POST /v1/{+attestor}:validateAttestationOccurrence

`POST /v1/{+attestor}:validateAttestationOccurrence`

Returns whether the given `Attestation` for the given image URI was signed by the given `Attestor`

## Path parameters

- `attestor` string, required

## Request body

- ValidateAttestationOccurrenceRequest — Request message for ValidationHelperV1.ValidateAttestationOccurrence.
  - `occurrenceNote` string — Required. The resource name of the Note to which the containing Occurrence is associated.
  - `occurrenceResourceUri` string — Required. The URI of the artifact (e.g. container image) that is the subject of the containing Occurrence.
  - `attestation` 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.
    - `serializedPayload` string, byte — Required. The serialized payload that is verified by one or more `signatures`.
    - `signatures` Signature[] — 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.
      - `signature` string, byte — 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.
      - `publicKeyId` 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. Examples of valid `public_key_id`s: 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"
    - `jwts` Jwt[] — 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.
      - `compactJwt` string — 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

## Response `200`

Successful response

---

[API](https://skmtc.dev/google/apis/binaryauthorization.md) · [All operations](https://skmtc.dev/google/apis/binaryauthorization/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/google/binaryauthorization/revisions/4e59b7e236cd/schema)