Change blobs to Descriptors (property name change)

[SteveLasker]

This issue tracks a proposal to change blobs to descriptors in the oras artifacts manifest

While this proposal makes a name change from blobs to descriptors, we are not changing the definition or scope of the property at this time. The name change is similar to changing subjectManifest to subject, enabling future changes.

{
  "artifactType": "application/vnd.cncf.notary.v2",
  "blobs": [
    {
      "mediaType": "application/tar",
      "digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0",
      "size": 32654
    }
  ],
  "subject": {
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "digest": "sha256:73c803930ea3ba1e54bc25c2bdc53edd0284c62ed651fe7b00369da519a3c333",
    "size": 16724
  }
}

becomes:

{
  "artifactType": "application/vnd.cncf.notary.v2",
  "descriptors": [
    {
      "mediaType": "application/tar",
      "digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0",
      "size": 32654
    }
  ],
  "subject": {
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "digest": "sha256:73c803930ea3ba1e54bc25c2bdc53edd0284c62ed651fe7b00369da519a3c333",
    "size": 16724
  }
}

Background

At KubeCon US 2021, @dmcgowan, @mikebrow and @SteveLasker were discussing how the artifacts spec might support index like scenarios. Including the ability for the oras artifact-spec to support redirects from one manifest request (tag/digest), to another based on some (TBD) element of data.

A future, possible flow could be:

1. On ingestion, a distribution instance (registry) would evaluate the mediaType in the descriptor.
2. 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.
3. If the mediaType is unknown, it would be treated as an opaque blob.

The above flow supports a fallback model where descriptors are treated as blobs, if unknown to the registry instance. However, it enables a registry to opt-into support of other manifest types.

Why Change Now

"Data lasts indefinitely"

In two words: "future proof".

As the oras artifacts spec is being adopted, it needs to account for future possibilities. The name change does not guarantee the artifact spec will support index scenarios, but it does free up a property name to support those scenarios as the maintainers have time to evaluate the impact.

[sajayantony]

LGTM provided we agree that this is about future proofing the spec and not change in scope and descriptors can only be blob descriptors.

[dmcgowan]

LGTM

It makes sense to have the field name represent the types underneath it. It is good to move away from "blobs" and "manifests" names as these are more related to the registry endpoint behavior rather than the data stored within the manifest.