Will there be one or two Confidential Storage specifications?

[agropper]

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.

[mwherman2000]

There seems to be consensus that EDVs are multi-tenant storage with each tenant having separate control of encryption keys and access authorization.

Please clarify. Yesterday we used the analogy of a single EDV being like a single physical post office mail box (with a key that can open the box ...you may have multiple physical keys but they are simple duplicates).

Question 1. Can a single EDV have multiple sets of different keys associated with it?

[mwherman2000]

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.

I'm advocating multiple specifications (at least two):

1. A Confidential Storage Core specification (aka CS Core aka EDV Core specification): Layers A, B and C of the current CS specification: https://identity.foundation/confidential-storage/#ecosystem-overview . Content Change Detection and Content Change Notifications would be part of the CS Core specification (as is the case in the current CS specification: sequence property). The current CS spec (indirectly) specifies USNs as the Content Change Detection model through the inclusion of the sequence property (which I support).
2. One or more Confidential Storage Services service specifications: that is, one or more specifications for each of the Layer D services. For example, there might one spec for Replication, another for Indexing and Search, etc. ...or the initial set of Layer D CS Services can be combined into a single second spec.

• The Confidential Storage Core specification would be mandatory with the scope limited to the mandatory features defined for Layers A, B, and C.
• With respect to the Confidential Storage Services specifications, some services might be deemed mandatory while the remainder of the services would default to optional.

In yesterday's call I referred to the above 2 concepts as the "proper partitioning of capabilities":

• CS Core (Layers A, B, C) vs. CS Services (Layer D).

It is assumed that the Confidential Storage Core specification has a sufficient feature set (e.g. includes base level features like Content Change Detection and Content Change Notifications) to support the requirements of all of the imagined Confidential Storage Services service specifications ...now and into the near future.

The reason why this is important is what Sam Curren (@telegramsam) calls the "Open to Innovation" principle: https://hyperonomy.com/2019/03/12/internet-protocols-and-standards-not-only-need-to-be-open-but-more-importantly-open-to-innovation/

[agropper]

There seems to be consensus that EDVs are multi-tenant storage with each tenant having separate control of encryption keys and access authorization.

Please clarify. Yesterday we used the analogy of a single EDV being like a single physical post office mail box (with a key that can open the box ...you may have multiple physical keys but they are simple duplicates).

Question 1. Can a single EDV have multiple sets of different keys associated with it?

I'm not sure the POBox is a useful analogy but let me try. The POBox represents one tenant in the location operated by the post office. The POBox tenant, as you point out, has very limited choices for delegating access because they have only one credential (the key). If they duplicate the credential, they violate some pretty basic security principles. Therefore, the POBox analogy only works to the extent that a client with the key can impersonate the tenant, by design.

If we want to continue and torture the POBox analogy, I would say the box contains a publicly accessible server with a physical USB fob that only someone with the key can replace. The fob stores the access authorization policies for the server. This policies control the way the server API for access, replication, or anything else exposed by the API. The tenant can, of course, bypass the API by simply removing the server from the box or they might just replace the fob with one that recognizes only their credential and nobody else's.

(PS: Some five years ago, as a consultant to the US Postal Service, I made the half-joking suggestion, that they could rent boxes with power and an ethernet jack.)

[mwherman2000]

I don't think my question was answered (reworded slightly):

UPDATED: Question 1. Can a single instance of an EDV (a la a single postal mail box if the analogy holds) have multiple different sets of keys associated with it?

[agropper]

What's a "single EDV"?

[mwherman2000]

UPDATED: Question 1. Can a single instance of an EDV (a la a single postal mail box if the analogy holds) have multiple different sets of keys associated with it?

Yes. Reference: https://identity.foundation/confidential-storage/#sharing-and-authorization

[agropper]

As with #169, it's extremely confusing to a normal person looking to understand a standard in terms of interoperability if we talk in terms of layers or hubs or instances. I raise this issue to seek clarity on what we expect for interoperability under this workgroup. Please consider the two alternatives at the top of this issue. If someone thinks there are other choices for our workgroup, please add them to the list.

[mwherman2000]

it's extremely confusing to a normal person looking to understand a standard

@agropper What is your specific definition of a normal person?

A lot of these technical and detailed terms (and their definitions) are critical to software architects, designers, and implementers. For example: ACID Transaction Scopes support statement missing from the specification

The Specification is an implementation and interoperability specification for EDVs. @msporny addressed in the DF SDS call 3-4 weeks ago.

[mwherman2000]

When I suggested there should be be 2 CS specification documents - one for CS Core and one for CS Services, here's a more specific visualization of what I had in mind...

[tahpot]

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.

I'm advocating multiple specifications (at least two)

I strongly support a conversation in due course to explore this idea of multiple specifications in order to produce something that is meaningful and useful in a reasonable time frame.

[OR13]

There will be 2