Add simpler top-level introductory definitions for EDVs and Identity Hubs

[dlongley]

From the June25th call some introductory definitions/explanations for EDVs and Identity Hubs were shared and we should try to get something like this into the spec as front matter:

An EDV can be thought of as a "new storage primitive" based on client-side encryption and encrypted indexes ... that changes the trust characteristics around storage providers. An "identity hub"... is a thing that helps you manage N EDVs ... and also has a set of rules for responding to queries about the data residing on those EDVs.

[dlongley]

An EDV server is a server that provides N EDVs -- knows nothing about what is stored in them, but enforces some authorization policy (potentially based on technologies such as ZCAP-LD or OAuth). Conceivably, those N EDVs may be controlled by entirely different entities (essentially a "multitenant" storage provider).

An "Identity Hub" can be used to help someone manage N EDVs spread across M EDV servers -- including the data that resides on these things and the rules around replicating it (in custom ways).

[agropper]

Here is a brief recap of issues I discussed around the definitions while trying not to bikeshed on names:

• Some of the layers will correspond to service endpoints in DID documents: -- Policy decision point -- Private storage, maybe encrypted -- Public storage -- Notification

• At least for Peer DIDs, privacy by default favors fewer endpoints, ideally just one https://github.com/w3c/did-core/issues/324#issue-641208223

• Access requests should be directed to the policy decision point to avoid unnecessary sharing of policies and to minimize the opportunity for traffic analysis linked to correlation of requesting parties.

• Datashards are one way to separate the policy decision point from the policy enforcement point(s).

• A capability is different from an access request. It can be processed by the policy enforcement point without requesting party claims, reasons for processing, or other policy-driven considerations.

• When an access request is presented to a private storage service endpoint, the request should be redirected to the policy decision point. The policy decision point might negotiate for more detailed claims from the requesting party in order to meet policy. The policy decision point may also contact the resource owner if the policy-based decision is inconclusive.

• Access requests to a public storage endpoint do not need to be redirected because no authorization is sought. The requesting party will minimize the data in their access request to protect their own privacy.

• Nothing prevents a service provider form offering both policy decision points and various storage services and offering the corresponding separate service endpoints to individual as well as enterprise customers.

• Some enterprise customers of a storage service provider will allow the data subject to specify the policy decision point in order for the enterprise to reduce their privacy risk and cost as a data controller. In these cases, we can assume that a data subject will present to the enterprise their policy decision point as a service endpoint along with a (Peer) DID.

• Some individual customers of a storage service provider will authenticate with a (Peer) DID and present their policy decision point as a service endpoint. In cases where the individual customer wants to include storage service endpoints in their DID document the storage service provider can offer a policy decision point as part of a "package". The self-sovereign individual customer will subsequently be able to change any of the service endpoints in the DID document at any time but may incur a cost in doing so. This cost should be the method-dependent cost of modifying a DID document but it should not otherwise inconvenience the customer in order to avoid lock-in to a package service provider.

[OR13]

@csuwildcat to help define these intro paragraphs / structure. please coordinate.