Will there be one or two Confidential Storage specifications?

There seems to be consensus that EDVs are multi-tenant storage with each tenant having separate control of encryption keys and access authorization. In other words, access authorization (ideally based on capability) is separate from and unrelated to encryption of the stored content and metadata, if any. In other words, the behavior and functionality of EDVs is to be agnostic or even blind to how and even if the data and metadata is encrypted.

The scope of features we are discussing appears to be about authorized access to an EDV be it specific to a presentation of a capability or pursuant to a pre-set policy such as replication. Conversely, the variety of clients that are presenting the capability or the target of a replication policy are not relevant to the EDV specification.

The EDV specification will likely include mandatory and optional features. As with our universal wallet conversation, we are concerned when two services claim EDV compliance but, for example, do not support optional attenuated delegation or filtered replication features.

To speed progress toward an EDV spec while also ensuring substitutability among EDV-labeled services in the cloud, we are considering moving some optional features of an EDV into a separately labeled and specified service. The presumption seems to be that a data subject or tenant of an EDV could independently choose a separate service that would add other access control or replication features on top of the EDV spec.

This separately labeled and specified service might, in effect be a client of the EDV just like other types of clients of the EDV, or not.

Our charter refers to “one or more specifications” but does not address optionality of features within a specification. I propose that we have the following choices:
1 - One specification called EDV with some optional features,
2 - Two specifications, one called EDV, with few or no optional features.
Choice (2) would allow us to co-develop the non-EDV spec to either replace or complement the EDV spec. Whichever we choose, we should be clear whether it’s an alternative or a complement.