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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated results shall be ordered first by the selected sortField, then by uuid as a deterministic secondary tie-breaker.

One of: name. Default: "name".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated results shall be ordered first by the selected sortField, then by uuid as a deterministic secondary tie-breaker.

When version is selected, ordering is by the stored version string according to the server's documented string collation; semantic-version precedence is not implied. Servers shall apply a stable and deterministic string collation for version sorting, and the same collation shall be used consistently across pages for a pagination sequence.

When releaseDate is selected, releases without a releaseDate shall be ordered consistently. Missing releaseDate values sort after populated releaseDate values for ascending order and before populated releaseDate values for descending order.

One of: createdDate, releaseDate, version. Default: "createdDate".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated results shall be ordered first by the selected sortField, then by uuid as a deterministic secondary tie-breaker.

When version is selected, ordering is by the stored version string according to the server's documented string collation; semantic-version precedence is not implied. Servers shall apply a stable and deterministic string collation for version sorting, and the same collation shall be used consistently across pages for a pagination sequence.

When releaseDate is selected, releases without a releaseDate shall be ordered consistently. Missing releaseDate values sort after populated releaseDate values for ascending order and before populated releaseDate values for descending order.

One of: createdDate, releaseDate, version. Default: "createdDate".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated results shall be ordered first by the selected sortField, then by uuid as a deterministic secondary tie-breaker.

One of: name. Default: "name".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated results shall be ordered first by the selected sortField, then by uuid as a deterministic secondary tie-breaker.

When version is selected, ordering is by the stored version string according to the server's documented string collation; semantic-version precedence is not implied. Servers shall apply a stable and deterministic string collation for version sorting, and the same collation shall be used consistently across pages for a pagination sequence.

When releaseDate is selected, releases without a releaseDate shall be ordered consistently. Missing releaseDate values sort after populated releaseDate values for ascending order and before populated releaseDate values for descending order.

One of: createdDate, releaseDate, version. Default: "createdDate".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated results shall be ordered first by the selected sortField, then by uuid as a deterministic secondary tie-breaker.

When version is selected, ordering is by the stored version string according to the server's documented string collation; semantic-version precedence is not implied. Servers shall apply a stable and deterministic string collation for version sorting, and the same collation shall be used consistently across pages for a pagination sequence.

When releaseDate is selected, releases without a releaseDate shall be ordered consistently. Missing releaseDate values sort after populated releaseDate values for ascending order and before populated releaseDate values for descending order.

One of: createdDate, releaseDate, version. Default: "createdDate".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated collection results shall be ordered first by the selected sortField, then by version as the deterministic secondary key if additional tie-breaking is needed. Collection UUIDs are not used as tie-breakers because collection UUIDs match the associated release UUID and can be shared across collection revisions.

The only currently supported collection sortField is version, so the secondary version key is redundant unless additional collection sort fields are added later.

One of: version. Default: "version".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

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.

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.

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.

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.

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.

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.

An opaque continuation token produced by a previous response. This token shall be copied verbatim from the nextPageToken value returned by the previous response. Clients shall not parse, construct, or modify this token.

The token represents continuation state for the original query, including sortField, sortOrder, result-affecting filters such as idType and idValue, and path parameters such as parent uuid. When pageToken is supplied, clients shall not change those result-affecting query parameters. Servers shall return 400 Bad Request if supplied result-affecting query parameters conflict with the token state. To change any result-affecting parameter, clients shall start a new pagination sequence without pageToken.

A pageToken is only valid with the same request path and same path parameter values used to obtain it. Clients shall not reuse a pageToken across different parent resource paths or different path uuid values. Servers shall return 400 Bad Request when a pageToken is used with a different path or different path parameter values.

Servers shall return 400 Bad Request for malformed, invalid, expired, or conflicting pageToken values.

The field by which to sort the results.

Paginated collection results shall be ordered first by the selected sortField, then by version as the deterministic secondary key if additional tie-breaking is needed. Collection UUIDs are not used as tie-breakers because collection UUIDs match the associated release UUID and can be shared across collection revisions.

The only currently supported collection sortField is version, so the secondary version key is redundant unless additional collection sort fields are added later.

One of: version. Default: "version".

The direction of the sort.

The default is asc for all paginated resources. Clients that need newest release or collection versions first can request sortOrder=desc.

The selected sort order applies to both the primary sortField and the resource-specific deterministic secondary tie-breaker. For products, components, product releases, and component releases, the secondary key is uuid. For collections, the secondary key is version if additional tie-breaking is needed.

One of: asc, desc. Default: "asc".

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Selects which of the artifact revision's formats to return, by its mediaType. The parameter value is the media type itself (for example application/vnd.cyclonedx+json), not a pre-encoded wire form. Clients shall apply query-parameter serialization once. Servers shall interpret the value after one query-decoding step.

Matching against a format's mediaType is case-insensitive for the type and subtype. Parameter names are compared case-insensitively; parameter values require exact equality. When omitted, the server selects a format using the request's Accept header per RFC 9110 section 12, and falls back to a format of its choice when Accept does not constrain the result. In either case the Content-Type of the response states which format was returned. An explicit mediaType can remove variation by Accept when it completely determines the format. When it does not, the server shall include Accept in Vary if changing or removing Accept could change the selected format, including when Accept is absent or contains */*. A mediaType query parameter does not eliminate variation by Accept-Encoding; see artifact-vary.

Example after serialization: .../download?mediaType=application%2Fvnd.cyclonedx%2Bjson

The content of the selected format of the latest revision of the TEA Artifact, as resolved at the time of the request.

Identical to artifact-content except for its cache policy: the latest revision changes when a new revision is published, so the response is not immutable and a cache shall revalidate it before reuse. Servers shall return a strong ETag for the selected HTTP representation. Revalidation returns 304 Not Modified when If-None-Match matches that representation's validator. Content-Location identifies the revision and format. Vary follows the same rules as artifact-content.

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.

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.

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.

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.

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.

The server shall provide a strong entity tag for the selected HTTP representation. Representations with different bytes shall have different strong entity tags, including representations that differ because of HTTP content coding. Artifact revision immutability does not require all HTTP representations of that revision to share an entity tag.

Intermediaries that compress on the fly often weaken the entity tag, which does not meet this requirement. Servers that offer content coding can serve precompressed variants, or assign their own strong entity tag to each coded representation.

The latest revision is a moving target: which revision it resolves to changes when a new revision is published. Servers shall not mark it immutable and shall require revalidation, so that a cache reuses a stored representation only after confirming, through that representation's ETag, that the selected representation has not changed.

As with versioned downloads, responses containing access-controlled content shall use private or no-store (for example private, no-cache). Servers shall use public only for content available without authorization.

If changing or removing the Accept request header could change the selected format for the same target URI, the server shall include Accept in Vary, including when Accept is absent or contains */* (RFC 9110 section 12.5.5). An explicit mediaType query parameter can remove variation by Accept when it completely determines the format.

If changing or removing the Accept-Encoding request header could change the selected content coding for the same target URI, the server shall include Accept-Encoding in Vary, including when Accept-Encoding is absent or the selected response uses no content coding. A mediaType query parameter does not eliminate variation by encoding.

Selects which of the artifact revision's formats the returned signature applies to, by that format's mediaType. This is the media type of the signed content, not of the signature. The parameter value is the media type itself, not a pre-encoded wire form. Clients shall apply query-parameter serialization once. Servers shall interpret the value after one query-decoding step.

Matching against a format's mediaType is case-insensitive for the type and subtype. Parameter names are compared case-insensitively; parameter values require exact equality. When omitted, the server selects a format of its choice. Requests that need a specific format's signature should supply this parameter. Successful responses include Content-Location with a mediaType query parameter naming the selected content format. An explicit mediaType can remove variation by Accept when it completely determines the signed format. It does not eliminate variation by Accept-Encoding; see artifact-vary.

Example after serialization: .../signature/download?mediaType=application%2Fvnd.cyclonedx%2Bjson

The detached signature for the selected format of the latest revision of the TEA Artifact, as resolved at the time of the request.

Identical to artifact-signature-content except for its cache policy: the latest revision changes when a new revision is published, so the response is not immutable and a cache shall revalidate it before reuse. Servers shall return a strong ETag for the selected HTTP representation. Revalidation returns 304 Not Modified when If-None-Match matches that representation's validator. Content-Location identifies the revision and format. Vary follows the same rules as artifact-signature-content.

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.

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.

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.

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.

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.

The latest revision is a moving target: which revision it resolves to changes when a new revision is published. Servers shall not mark it immutable and shall require revalidation, so that a cache reuses a stored representation only after confirming, through that representation's ETag, that the selected representation has not changed.

As with versioned downloads, responses containing access-controlled content shall use private or no-store (for example private, no-cache). Servers shall use public only for content available without authorization.

If changing or removing the Accept request header could change the selected format for the same target URI, the server shall include Accept in Vary, including when Accept is absent or contains */* (RFC 9110 section 12.5.5). An explicit mediaType query parameter can remove variation by Accept when it completely determines the format.

If changing or removing the Accept-Encoding request header could change the selected content coding for the same target URI, the server shall include Accept-Encoding in Vary, including when Accept-Encoding is absent or the selected response uses no content coding. A mediaType query parameter does not eliminate variation by encoding.

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.

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.

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.

Selects which of the artifact revision's formats to return, by its mediaType. The parameter value is the media type itself (for example application/vnd.cyclonedx+json), not a pre-encoded wire form. Clients shall apply query-parameter serialization once. Servers shall interpret the value after one query-decoding step.

Matching against a format's mediaType is case-insensitive for the type and subtype. Parameter names are compared case-insensitively; parameter values require exact equality. When omitted, the server selects a format using the request's Accept header per RFC 9110 section 12, and falls back to a format of its choice when Accept does not constrain the result. In either case the Content-Type of the response states which format was returned. An explicit mediaType can remove variation by Accept when it completely determines the format. When it does not, the server shall include Accept in Vary if changing or removing Accept could change the selected format, including when Accept is absent or contains */*. A mediaType query parameter does not eliminate variation by Accept-Encoding; see artifact-vary.

Example after serialization: .../download?mediaType=application%2Fvnd.cyclonedx%2Bjson

The content of the requested TEA Artifact format.

The wire Content-Type is the mediaType of the format returned. The response content key is */* because that type varies by format. 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.

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.

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.

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.

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.

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.

The server shall provide a strong entity tag for the selected HTTP representation. Representations with different bytes shall have different strong entity tags, including representations that differ because of HTTP content coding. Artifact revision immutability does not require all HTTP representations of that revision to share an entity tag.

Intermediaries that compress on the fly often weaken the entity tag, which does not meet this requirement. Servers that offer content coding can serve precompressed variants, or assign their own strong entity tag to each coded representation.

Cache policy for a specific artifact or signature revision. Artifact and signature bytes remain unchanged after HTTP decoding. A server may use immutable only when the selected HTTP representation, including its content-coded bytes, will remain unchanged throughout the response's freshness lifetime. Otherwise, the server shall omit immutable.

Responses containing access-controlled content shall use Cache-Control private or no-store. Servers shall use public only for content available without authorization. Immutability does not imply public accessibility (see RFC 9111 section 5.2.2.9).

If changing or removing the Accept request header could change the selected format for the same target URI, the server shall include Accept in Vary, including when Accept is absent or contains */* (RFC 9110 section 12.5.5). An explicit mediaType query parameter can remove variation by Accept when it completely determines the format.

If changing or removing the Accept-Encoding request header could change the selected content coding for the same target URI, the server shall include Accept-Encoding in Vary, including when Accept-Encoding is absent or the selected response uses no content coding. A mediaType query parameter does not eliminate variation by encoding.

Selects which of the artifact revision's formats the returned signature applies to, by that format's mediaType. This is the media type of the signed content, not of the signature. The parameter value is the media type itself, not a pre-encoded wire form. Clients shall apply query-parameter serialization once. Servers shall interpret the value after one query-decoding step.

Matching against a format's mediaType is case-insensitive for the type and subtype. Parameter names are compared case-insensitively; parameter values require exact equality. When omitted, the server selects a format of its choice. Requests that need a specific format's signature should supply this parameter. Successful responses include Content-Location with a mediaType query parameter naming the selected content format. An explicit mediaType can remove variation by Accept when it completely determines the signed format. It does not eliminate variation by Accept-Encoding; see artifact-vary.

Example after serialization: .../signature/download?mediaType=application%2Fvnd.cyclonedx%2Bjson

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.

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.

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.

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.

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.

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.

Cache policy for a specific artifact or signature revision. Artifact and signature bytes remain unchanged after HTTP decoding. A server may use immutable only when the selected HTTP representation, including its content-coded bytes, will remain unchanged throughout the response's freshness lifetime. Otherwise, the server shall omit immutable.

Responses containing access-controlled content shall use Cache-Control private or no-store. Servers shall use public only for content available without authorization. Immutability does not imply public accessibility (see RFC 9111 section 5.2.2.9).

If changing or removing the Accept request header could change the selected format for the same target URI, the server shall include Accept in Vary, including when Accept is absent or contains */* (RFC 9110 section 12.5.5). An explicit mediaType query parameter can remove variation by Accept when it completely determines the format.

If changing or removing the Accept-Encoding request header could change the selected content coding for the same target URI, the server shall include Accept-Encoding in Vary, including when Accept-Encoding is absent or the selected response uses no content coding. A mediaType query parameter does not eliminate variation by encoding.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.