# Summary of KubeCon discussions around CNAB in OCI Registries

## TL;DR
- propose changes to OCI to introduce a `config` object for an index (which includes a `mediaType` attribute), and a `remote` field for manifests
- use `cnab-to-oci` while spec changes are discussed, and decide how / if the complete `bundle.json` should be stored in the registry

## Summary

- there was a meeting with representatives from Red Hat (Quay), IBM, Harbor, Docker, Microsoft, and an OCI Specification maintainer (Jimmy Zelinskie)
- [Steve's meeting notes](https://hackmd.io/s/S1X6JNnTN)

- the first part of the discussion was a high level overview about different media types supported by OCI registries (Helm charts, OPA bundles) and how registries should handle unknown media types, and user requests to support new media types - for more info on this, Steve Lasker (Azure Container Registries), Joey Schorr (Quay) could be great people to ask. There appears to be consensus around using ORAS for storing these types of artifacts.

- CNABs are different to individual artifacts stored in a registry as they reference multiple artifacts. An OCI index is a closer fit for modeling this in a registry than a manifest.

- one property an OCI index doesn't have today is a `config` object, which means an OCI index cannot have an additional `mediaType` - everyone in the meeting thought the OCI specification should add this, and a change in the specification should be proposed.

- if the OCI index has an additional `mediaType`, there could be one for CNAB, and `cnab-to-oci` wouldn't rely on annotations for this anymore.

- an OCI index is a collection of artifacts - however, according to the current OCI specification, all artifacts referenced in an OCI index must be found in the same repository - meaning that if we used an OCI index in its current form, we would impose all registries to allow multiple artifacts (and potentially multiple artifact types) in the same repository - to relax this, an additional change to the specification should be proposed - the addition of an optional `remote` field for manifests in an index that would specify the referenced manifest is part of a different repositrory, or potentially a different registry.

- while the OCI specification changes are discussed, we could use `cnab-to-oci`, since it requires minimal changes from its current implementation. We should try not to fragment registry storage efforts. `cnab-to-oci` requires some changes to support some of the flows shown in community meetings (image relocation, etc.)

- discussion around storing the complete `bundle.json` file (and duplicate the information about the reference images) vs. reconstructing it based on a configuration file (parameters, credentials, metadata - all other fields in `bundle.json`) and the referenced images. Whatever path we choose, the proposed changes to the OCI specification should allow both options. Same goes for signing - whether we choose to sign the complete `bundle.json` that is stored in the registry, or we sign the manifest generated by the registry, the proposed changes to the specification and the current CNAB security spec should allow for for both approaches.

- the air gapped story for CNAB can come from [OCI image layouts](https://github.com/opencontainers/image-spec/blob/master/image-layout.md).