Enable generating OpenContainers annotations from Wasm Components

One of the design principles behind the Wasm OCI Artifact Layout is that it operates as a thin wrapper around Wasm Component binaries. Ideally this would mean that it is possible to decode an OCI image to a Wasm Component, and re-encode it back as OCI (roundtrip) without losing any information.

OCI images support a standard set of annotations for metadata, used by registries such as GitHub Container Registry and Azure Container Registry in their respective interfaces. These annotations are documented as part of the OpenContainers Annotation Spec. This specification contains metadata such as the date/time when the image was created, the license the image has, who the image was published by, and who the image was published by.

This data seems very useful to provide, and people are starting to provide that data already today. I would like to propose we establish tooling conventions for how to encode this data in custom sections inside of Wasm binaries today. That way language toolchains can directly encode that metadata as part of the binaries they produce. And all Wasm-specific OCI tooling has to do, is take that metadata from the components and encode that as OpenContainers annotations.

Before diving into any concrete proposal for which custom sections we might want to add and how we'd encode those - I wanted to raise this issue to put feelers out for how people might feel about this. I saw folks were generally positive about https://github.com/WebAssembly/tool-conventions/issues/141 which proposed adding a section on documentation, though the issue hasn't seen any activity for a while. If people are generally optimistic about the what I'm proposing here, I'd be happy to open a PR with initial wording for, say, SPDX license identifiers encoded in a custom section to get the ball rolling on this.

Thanks!

Start by reading the Wasm OCI Artifact Layout and OpenContainers Annotation Spec linked in the issue, then review related issue #141. The issue is seeking community agreement on custom sections and encoding conventions; a concrete definition of done is not established until that proposal is resolved.