The image spec mentions multiple registered digest algorithms (https://github.com/opencontainers/image-spec/blob/v1.1.0-rc5/descriptor.md#digests), out of which SHA256 is the canonical one.

The distribution spec mentions these registered digest algorithms can be used to reference manifests when:
A) pulling - https://github.com/opencontainers/distribution-spec/blob/v1.1.0-rc3/spec.md#pulling-manifests

The Docker-Content-Digest header, if present on the response, returns the canonical digest of the uploaded blob which MAY differ from the provided digest. If the digest does differ, it MAY be the case that the hashing algorithms used do not match. See [Content Digests](https://github.com/opencontainers/image-spec/blob/v1.0.1/descriptor.md#digests) [apdx-3](https://github.com/opencontainers/distribution-spec/blob/v1.1.0-rc3/spec.md#appendix) for information on how to detect the hashing algorithm in use. Most clients MAY ignore the value, but if it is used, the client MUST verify the value against the uploaded blob data.

B) pushing - https://github.com/opencontainers/distribution-spec/blob/v1.1.0-rc3/spec.md#pushing-manifests

The <location> is a pullable manifest URL. The Docker-Content-Digest header returns the canonical digest of the uploaded blob, and MUST be equal to the client provided digest. Clients MAY ignore the value but if it is used, the client SHOULD verify the value against the uploaded blob data.

Case A) seems relatively clear to me, but in case B) the expected behavior of the registry is not entirely clear to me, as the digest (and the implicitly the algorithm) may or may not be provided by the client.

I assume the MUST be equal to the client provided digest is the value of the reference.
The clarifications needed are:

1. In case the reference is a digest, and it is using a non-canonical digest algorithm, how can it be equal to the Docker-Content-Digest header value which is always using the canonical digest algorithm?
2. In case the reference is a tag, is there a way for the server to know what algorithm it should use to track this manifest?

• Is the registry supposed to only use the canonical algorithm in this case? That could cause issues if the client pushes another manifest referencing the initial manifest by a digest computed using a non-canonical algorithm.
• Is the registry supposed to compute all possible hashes, using all registered algorithms, of a given manifest (or blob in general) in order to make sure any possible future references can be successfully resolved?

If this topic has already been discussed or documented, please provide a link, I could not find relevant issues here.

Thank you