[dlor]

Yep - a new version of image spec and distribution spec (not runtime spec).

This version allows for formalized ways to store other types of content in registries (think Helm Charts, OPA policies, etc.), as well as a way to "attach" arbitrary content to registries and then retrieve it later.

Both of these are powerful and will have lots of use cases, but the primary ones at this point are focused on supply chain security - storing content like SBOMs, digital signatures and attestations.

[jauntywundrkind]

> This version allows for formalized ways to store other types of content in registries (think Helm Charts, OPA policies, etc.), as well as a way to "attach" arbitrary content to registries and then retrieve it later.

First part seems right. I think though that part two is maybe misworded or what not? It allows artifacts of any kind to ne attached/related to other artifacts.

From the oci blog post, the example is uploading a software-bill-of-material sbom & having it attached to the container it represents. Such that a user can then query of there is an sbom for their container & get a list of such sboms (you can also ask for an index of all related content).

[jdolitsky]

SBOMs may be an important short-term use-case, but ultimately the spec will now provide a "blessed" way to attach even a cat picture. It can be uploaded standalone or pointing to a container image.

The way to indicate a non-container artifact type is to use the "artifactType" field. Your client may choose whether or not to support older <=v1.0 registries by falling back to use "config.mediaType". The way to attach the artifact to the image is to use the "subject" field, pointing "subject.digest" to the proper digest of the thing you're pointing to (e.g. "sha256:..." ). There are no limitations there either, you may point cat pictures to cat pictures.