docs(101-bundle-json.md): add clarification around contentDigest value

[vdice]

• Clarifies which type of digest must be used for the contentDigest field of an invocation or bundle image

Proposed fix for #287

[carolynvs]

LGTM 👍

[SteveLasker]

Curious why the digest is required to be consistent with the tag.
While deploying unique tags is a best practice to have consistent deployments across a scale unit, locking to the digest blocks the "break glass" servicing capability. I get that some use docker-lock type rules until we have a better signing, or standard tag locking capability. Just suggesting this shouldn't be a hard requirement.

As a minor point, some of the references refer to "image":"example/microservice:1.2.3"
This is a bit confusing. Is this the default docker hub behavior where no registry = docker.io? Or, does the bundle support finding the image in the registry where the CNAB bundle was pulled from?
There's some later examples of: "image": "example.com/example/vote-frontend@sha256:aca460afa270d4c527981ef9ca4989346c56cf9b20217dcea37df1ece8120685",
Would suggest fully qualified names, if that's what it means, or better yet, support reference artifacts to the registry where the CNAB was pulled enabling better transportability.

For the image reference, the spec states:

The following OPTIONAL fields MAY be attached to an invocation image:
size: The image size in bytes. Implementations SHOULD verify this when a bundle is packaged as a thick bundle, and MAY verify it when the image is part of a thin bundle.

Would suggest requiring the full OCI Descriptor information, where digest, mediaType and size are required.

[chris-crone]

LGTM

This is a clarification but it would, in theory, break runtimes that use a different contentDigest definition so I believe that rules this out as a simple errata. We'll need to bump the spec version.

[vdice]

@SteveLasker good points, all. Please feel free to create follow-up issues for spec amendments/proposals mentioned. However, the scope of this changeset is simply to clarify the expected value of the contentDigest field when the invocation image type is docker/oci.

[trishankatdatadog]

Hmm, interesting. Would this break Signy's verification behaviour, @radu-matei? I suppose not unless you consider copying images between different registries?

[technosophos]

LGTM. Much clearer and precise this way.

[chris-crone]

Hmm, interesting. Would this break Signy's verification behaviour, @radu-matei? I suppose not unless you consider copying images between different registries?

I remember having discussions about this with @radu-matei so I think he likely implemented Signy with this definition in mind

[silvin-lubecki]

LGTM 👍