Blobs descriptors

[SteveLasker]

Fixes #73 There is no scope change with this PR. This is a property change only, enabling the future possibility for [descriptors] to reference other manifests, similar to the index.

• If the artifacts spec never supports oci.index like scenarios, descriptors is still accurate.
• If the artifacts spec does add support for oci.index like scenarios, blobs could be a weirdly named property. Even tho manifests may be stored as blobs.
• If the artifacts spec does add support, the spec will need more work, and possibly additional properties to define the type of descriptor.

[justincormack]

I don't really understand the use case "If the mediaType is know to be a manifest, supported by the registry, it would parse the manifest and possibly track additional lifecycle management links." in the issue - can someone elaborate?

[SteveLasker]

The use case is: Can the ORAS artifact manifest be used for OCI Index scenarios? Within the artifacts conversations, we've talked about improving Index to have blobs and a means to define the artifactType. For instance, CNAB or Helm type scenarios where you want to reference a chart, and multiple images.

In theory, the blobs collection could contain the helm chart content, and references to the images:

{
  "artifactType": "application/vnd.cncf.helm.vFuture+json",
  "blobs": [
    {
      "comment": "helm chart config",
      "mediaType": "application/vnd.cncf.helm.config.v1+json",
      "digest": "sha256:e752324f6804d5d0b2c098f84507d095a8fd0031cf06cdb3c7ad1625dcd1b399",
      "size": 7097
    },
    {
      "comment": "helm chart",
      "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip",
      "digest": "sha256:83c5cfdaa5385ea6fc4d31e724fd4dc5d74de847a7bdd968555b8f2c558dac0e",
      "size": 25851449
    },
    {
      "comment": "helm chart provenance",
      "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov",
      "digest": "sha256:7445693bd43e8246a8c166233392b33143f7f5e396c480f74538e5738fb6bd6e",
      "size": 226
    },
    {
      "comment": "wordpress-image",
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:8145693bd43e8246a8c166233392b33143f7f5e396c480f74538e5738fb6bd18",
      "size": 1023
    },
    {
      "comment": "mysql",
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:3785693bd43e8246a8c166233392b33143f7f5e396c480f74538e5738fb6g27",
      "size": 3014
    }
  ]
}

It could also just replace the current OCI Index and just be a multi-arch index of content in the same repository.

I've minimized the amount of content in the parent issue: #73, as we're really just scoping a name change for now. We think there's something here to explore, but we haven't finished exploring it.

• At best, we can do some derivatives of the above scenarios.
• At worst, we never change the scope, and just have a property called descriptor, vs. blobs
• Or, another worst-case scenario, we do enable index scenarios, but we didn't rename the property, and now we're explaining why we're storing manifests in a blobs collection :(. Which is the same confusion we have around buildx storing blobs in the index.manifests collection

As to how the logic might work. If the registry knows the mediaType is a manifest, it can parse the manifest and store the reference. The idea is the registry doesn't have to know the mediaTypes to store the information. It just has the option of parsing the information. This clearly needs more thoughts. Thus, it's just a name change for now. No scope change.

[SteveLasker]

Merging the change. We'll need to queue up changes to ORAS and notation to support the updated format. We'll queue this up for the next release. We'd also like to take the base path for the referrers API as a change in the next release.