The Docker, Helm, and Docker Model registries are based on the OCI manifest protocol. They identify an artifact's type and accept or reject the push according to the Artifact Type Admission Restrictions. Identification rules:

• The config mediaType determines the artifact type (e.g. vnd.oci.image.config.v1+json is classified as a container image).
• Some types require an additional check on manifest layers (e.g. an empty-config artifact is only recognized as Attestation when all of its layers are application/vnd.in-toto+json layers carrying the in-toto.io/predicate-type annotation; otherwise it is UNKNOWN).

Scope

This appendix only applies to the Docker, Helm, and Docker Model OCI registries. Other registries such as Maven, npm, and PyPI use their own native protocols and do not involve manifest type identification.

Docker Registry

Artifact Type	config mediaType	Additional Condition	Typical Scenario
Container image (IMAGE)	application/vnd.oci.image.config.v1+json	—	Images pushed via docker push / docker buildx build --push
Container image (IMAGE)	application/vnd.docker.container.image.v1+json	—	Images in Docker schema2 format
buildx registry cache (BUILD_CACHE)	application/vnd.buildkit.cacheconfig.v0	—	Build cache pushed via docker buildx build --cache-to type=registry
Attestation (ATTESTATION)	application/vnd.oci.empty.v1+json	config must be the standard empty descriptor (fixed digest, size 2), and all manifest layers must be application/vnd.in-toto+json layers carrying a non-empty in-toto.io/predicate-type annotation	Provenance/SBOM attestations produced by buildx builds

The index of a multi-arch image (application/vnd.oci.image.index.v1+json or application/vnd.docker.distribution.manifest.list.v2+json) is accepted together with its child manifests and requires no separate configuration.

Note

• Attestation identification requires all of the following: config is the standard application/vnd.oci.empty.v1+json empty descriptor (digest sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a, size 2), and all manifest layers are application/vnd.in-toto+json layers carrying a non-empty in-toto.io/predicate-type annotation (i.e. a real buildkit provenance/SBOM), with at most 16 layers. An artifact that fails these conditions (e.g. a generic artifact pushed by oras push with default empty config, a forged in-toto mediaType without the predicate-type annotation, or one that mixes in non-in-toto layers) is classified as UNKNOWN and will be rejected when pushed to the Docker registry.
• Generic OCI artifacts with a custom config mediaType (e.g. application/vnd.myapp.config.v1+json) are currently not supported by the Docker registry and will be rejected.
• Attestation identification is heuristic and does not constitute a supply chain security boundary: manifest fields are controlled by the pusher and can theoretically be forged to bypass type checks. The registry only handles type routing and storage; it does not verify the authenticity or signature of attestation content.

Helm Registry

Artifact Type	config mediaType	Typical Scenario
Helm Chart (CHART)	application/vnd.cncf.helm.config.v1+json	helm push (OCI format)

Docker Model Registry

Artifact Type	config mediaType	Typical Scenario
Docker Model (DockerModel)	application/vnd.docker.ai.model.config.v0.1+json	docker model push

Rejection Error

When pushing a type that is not on the allowlist, the following error is returned. Blobs already uploaded are cleaned up automatically by garbage collection (GC):

denied: artifact type "CHART" is not allowed to be pushed to a "docker" registry

Previous pageConan Artifact Repository