Added encryption mediatype doc

[lumjjb]

Following discussions in https://github.com/opencontainers/image-spec/pull/775, adding details on encrypted mediatype definitions.

Signed-off-by: Brandon Lum [email protected]

[lumjjb]

Thanks for the fixes, @vbatts. Pushed the changes.

[vbatts]

@SteveLasker what is the plan for merging things into this artifacts project?

[SteveLasker]

Great question. To be honest, I've been focused on how we add new artifacts, and how we can link artifacts together with reference types, including the reverse lookup pattern. (like Notary, SBoM, GPL, ...) Artifacts PR#27 I see this conversation more about how a specific artifact type (Images) adds new capabilities to their artifact type and schema. The debate prior to the new year was: how do we add new compression to an existing type, without breaking the existing users. Happy to expand the artifacts conversation to talk more about it. May a good discussion for next Wednesday?

[mikebrow]

suggest creating an incoming or under-consideration path for artifacts in progress and an approved path for artifacts approved...

this is more a common extension but I'd still put it in the incoming till we push an artifact type to the approved path that has optional / required dependency on this.. and for when we can get approval from the owner of the artifact type that this extension is approved for said type.

[SteveLasker]

suggest creating an incoming or under-consideration path for artifacts in progress and an approved path for artifacts approved...

This is great suggestion. Reviewing the pr again, this looks like a way to define how encryption can be done on any artifact type.

[lumjjb]

The PR is updated addressing the comments... Hmm since we were recently discussing this, are there plans to move this forward at the moment?

[SteveLasker]

@lumjjb, we've been discussing how we can enable flexibility to the manifests to support versioning within an artifact type. @justincormack has been proposing #37 as a superset of #29 to address these types of needs. Can I suggest some :eyes: on #37 to get your input for how it may or may not solve encryption capabilities?

[lumjjb]

Sounds good, i'll take a look at #37

[jonjohnsonjr]

@justincormack has been proposing #37 as a superset of #29 to address these types of needs.

That's not what superset means