PROPOSAL: Confidential Storage Specification Refactoring 0.1 – March 24, 2021
PROPOSAL: Confidential Storage Specification Refactoring 0.1 – March 24, 2021
Based on the March 11 Zoom discussion where we worked hard to discern the differences between Agents, Hubs, and EDVs (and I believe were largely successful IMO), I’ve like to propose to the SDS/CS WG that we refactor the current Confidential Storage specification into 3 separable parts/specifications. I also present a high-level roadmap (simple ordering) for how the WG might proceed if this refactoring is accepted (or at least, if the first part/first new specification is accepted).
Separable Part 1: Factor the current EDV-related components of the current Confidential Specification into its own specification document. This document would be a ZCAP/HTTP-specific specification document for EDVs. I also propose that the title of this specification document clearly reflect that orientation. For example, the proposed title for this specification document is: EDV Specification 1.0: ZCAP/HTTP Data Vault Storage.
Separable Part 2: Factor the Hub-related components of the current Confidential Specification into its own specification document. This document would define the Hub components that an Agent or App can talk to as well as describe how a Hub “sits on top of an EDV service instance”. I also propose that the title of this specification document clearly reflect that orientation. For example, the proposed title for this specification document is: Data Hub Specification 1.0: Federated (or Aggregated) Personal Data Access (or something like that).
Separable Part 3: Develop a specification for the Layer A Trusted Content Storage Kernel as its own specification document (see the diagram below). This document would document a public lower-level interface for directly interacting with local-device hosted/attached EDVs without needing or requiring a higher-level remote access protocol (e.g. HTTP). I also propose that the title of this specification document clearly reflect that orientation. For example, the proposed title for this specification document is: EDV Kernel Specification 1.0: Layer A Trusted Content Storage Kernel. This is in support of apps like the Fully Decentralized Dewitter scenario.
Roadmap: The scope of the above specifications and a high-level roadmap (simple ordering) for these specifications is illustrated below.
Best regards, Michael Herman Far Left Self-Sovereignist
Self-Sovereign Blockchain Architect Trusted Digital Web Hyperonomy Digital Identity Lab Parallelspace Corporation
|
|
Manu Sporny
On 3/24/21 12:05 PM, Michael Herman (Trusted Digital Web) wrote:
*PROPOSAL: Confidential Storage Specification Refactoring 0.1 – March 24,+1 for at least separating the Hub calls from the EDV calls, we finally have at least those two rough buckets after a year of work. I don't know if we have enough consensus yet to split the specs, but would be interested in hearing from folks as they've seemed like oil on water since we put them together over a year ago. If we were to split the specs, I'd like to keep the low-level EDV stuff together with the HTTP API for the EDV (for the time being). We could naturally split them apart later... but given that we don't have anyone doing a local API for an EDV yet, I hesitate to split the spec apart on theoretical grounds that we're going to end up there. I see nothing wrong w/ defining both the local API and HTTP API in the same document (and then splitting the HTTP API out later). Just my $0.02... -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches |
|