---
title: "Download the signature of one TEA Artifact revision"
method: GET
path: "/artifact/{uuid}/{artifactVersion}/signature/download"
tags: ["TEA Artifact"]
---

# Download the signature of one TEA Artifact revision

`GET /artifact/{uuid}/{artifactVersion}/signature/download`

Download the detached signature for one format of a specific revision of a
specific TEA Artifact.

This is the counterpart of the artifact content endpoint, for TEA servers that
host signatures themselves: a format that has no external `signatureUrl` is
retrieved from here, selected by its `mediaType`. A format that has a
`signatureUrl` is retrieved from that external location instead, and this
endpoint is not required to serve it.

Signatures are per format: each format of a revision is a distinct sequence of
bytes and therefore has its own signature. The `mediaType` parameter selects which
format's signature is returned, not the format of the signature itself.

This specification makes no assumption about the signature technology in use, and
does not model the signing algorithm, key, or certificate chain; the response is
the signature as published. A client that cannot determine how to verify what it
receives should treat the signature as unusable rather than as invalid.

`404` distinguishes the cases by TEA error body: `OBJECT_UNKNOWN` when the
artifact revision is unknown (or concealed), and `SIGNATURE_NOT_FOUND` when the
revision exists but the selected format has no signature published. A server
concealing an artifact from a client shall answer `OBJECT_UNKNOWN` for every
sub-resource of it, including signatures.

When serving the signature itself (`200`), servers shall return a strong `ETag`
for the HTTP representation selected after negotiation, including content
coding, and shall honor `If-None-Match` with `304`.
`ETag` is the only conditional validator for these downloads. Servers that support
`HEAD` for this operation shall return the same headers as `GET` without a response
body.
`302` redirects are outside conditional semantics: `If-None-Match` applies only
to the TEA-hosted download response, not to following an external `Location`.
Successful responses include `Content-Location` as an absolute URL of this
versioned signature download including the `mediaType` query parameter. That URL
identifies the revision and format; HTTP content coding can still be negotiated.

## Path parameters

- `uuid` string, uuid, required — A UUID in lower case (RFC 9562)
- `artifactVersion` integer, required

## Query parameters

- `mediaType` string

## Headers

- `If-None-Match` string

## Response `200`

The detached signature for the selected format of the TEA Artifact revision.

The wire `Content-Type` is `application/octet-stream` unless the server knows a
more specific media type for the signature it holds, in which case it returns
that. The response content key is `*/*` because that type may vary. This
specification does not require servers to identify the signature technology.
`Content-Encoding`, when present, names the HTTP content coding of the selected
representation. `Content-Location` identifies the revision and format; HTTP
content coding can still be negotiated. `Vary` follows `artifact-vary`.

## Other responses

- `302` — The selected representation is available at another location, for example object storage addressed by a pre-signed URL. The client follows the `Location` header. Changing only this response's `Location`, while preserving the artifact or signature bytes for the selected UUID, version, and format after HTTP content coding is removed, does not require a new artifact or collection version. Publishing a different external `url` or `signatureUrl` on the artifact metadata is a separate change and shall follow the `artifact-format` rules for those fields. A client shall not send its TEA access token when following a redirect to a different origin.
- `304` — The representation selected after negotiation has not changed (RFC 9110). The response body is empty. Servers shall repeat `ETag` and `Content-Location` from the would-be successful response for that representation, and shall repeat `Cache-Control` and `Vary` when the corresponding `200` carries them.
- `400` — Request was invalid. For paginated requests, this includes malformed, invalid, expired, or conflicting `pageToken` values, including conflicts with continuation parameters or path parameters (`error: INVALID_PAGE_TOKEN` when a TEA error body is present). Other malformed requests may use `error: INVALID_REQUEST`.
- `401` — Authentication required, or the presented access token is expired, revoked, or otherwise invalid. Servers shall include a `WWW-Authenticate` header as defined in RFC 6750 section 3. On the `invalid_token` error a client may obtain a fresh token from `/token` and retry the request once (RFC 6750 section 3.1). The `WWW-Authenticate` challenge remains the primary signal; an `error-response` body is optional. Servers that require no authentication on any endpoint shall not return this status. On a TEA server where some data is available without authentication, but not all, protected endpoints return `401` when no valid token is presented; endpoints that do not require authentication answer without requiring a Bearer token. A protected object shall not answer `404` solely because the client is unauthenticated: absence of a valid token yields `401`, so the client flow can discover that authentication is required.
- `403` — The client is authenticated, but is not authorized to access this resource or perform this operation. Authorization decisions are server-specific and are not constrained by this specification. Servers may instead conceal the existence of a resource from an authenticated but unauthorized client by answering `404` (see `404-object-by-id-not-found`). Clients shall treat `403` and that concealing `404` as non-access; neither implies that retrying with the same token will succeed.
- `404` — Either the object is unknown to this server, or — where an endpoint documents it — the server does not provide an optional capability or sub-resource for that object. The cases are told apart by the TEA error body, never by the status alone: - `error: OBJECT_UNKNOWN` — no such object (or its existence is concealed from this client). - `error: NOT_IMPLEMENTED` — optional capability or endpoint not provided (for CLE: lifecycle data; for `/token`: the token endpoint is not implemented). CLE is optional in TEA; clients shall not treat this as a failure of the object itself where the capability is optional. - `error: SIGNATURE_NOT_FOUND` — the artifact revision and format exist, but no signature is published for that format. This reveals that the artifact exists; a server concealing an artifact shall answer `OBJECT_UNKNOWN` for every sub-resource of it, signatures included. Concealment applies only after authentication. A request to a protected object with no valid access token shall receive `401` (see `401-unauthorized`), not a concealing `404`. Clients shall not infer from `404` alone whether the object is absent, withheld, or lacking an optional capability or sub-resource.
- `406` — The artifact revision exists, but has no format matching the requested `mediaType` or `Accept` header. Body is a TEA `error-response` with `error: NO_ACCEPTABLE_FORMAT`. `NO_ACCEPTABLE_FORMAT` reveals that the artifact revision exists. A server concealing an artifact from a client shall answer `404` with `error: OBJECT_UNKNOWN` for every sub-resource of it, formats included, instead of this status.

## Changes

- **2026-09-23** `4f09e14d1ee0` — 3 warning
  - the optional response header `Content-Encoding` removed for the status `200`
  - the optional response header `Repr-Digest` removed for the status `200`
  - the optional response header `Vary` removed for the status `200`
- **2026-09-23** `03c7ffdc11d0` — 3 warning
  - the optional response header `Content-Encoding` removed for the status `200`
  - the optional response header `Repr-Digest` removed for the status `200`
  - the optional response header `Vary` removed for the status `200`
- **2026-09-20** `f698addb5d2b` — 10 info
  - added the optional property `message` to the response with the `400` status
  - added the optional property `message` to the response with the `401` status
  - added the optional property `message` to the response with the `403` status
  - added the optional property `message` to the response with the `404` status
  - …6 more
- **2026-09-20** `56e8a7148549` — 1 breaking, 3 info
  - removed the media type `application/octet-stream` for the response with the status `200`
  - added the new optional `header` request parameter `If-None-Match`
  - added the media type `*/*` for the response with the status `200`
  - added the non-success response with the status `304`
- …earlier changes not shown

[Full history](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/changes/artifact/:uuid/:artifactVersion/signature/download/get.md)

---

[API](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api.md) · [All operations](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/llms.txt) · [OpenAPI document](https://skmtc.dev/cyclonedx/apis/transparency-exchange-api/revisions/4d4c7959bc18?raw)