Why is it good to think of a Glossary as a Network of Balls connected by Elastics?
From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net> Sent: March 24, 2021 8:47 AM To: Leonard Rosenthol <lrosenth@adobe.com>; David Waite <dwaite@pingidentity.com>; Jim St.Clair <jim.stclair@lumedic.io> Cc: Drummond Reed <drummond.reed@evernym.com>; sankarshan <sankarshan@dhiway.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>; Hardman, Daniel <Daniel.Hardman@sicpa.com> Subject: TDW Glossary [was: The “self-sovereign” problem (was: The SSI protocols challenge)]
RE: First and foremost, without a definition/clarification of “Verifiable”, both of your statements are ambiguous.
Leonard, I don’t disagree with your feedback. What I have been rolling out to the community is selected neighborhoods of closely related terms from the TDW Glossary project.
[A Glossary is] like a bunch of balls explicitly connected by elastics: add a new ball to the model and all of the existing balls in the neighborhood need to adjust themselves. The more balls you have in the network, the more stable the network becomes. So it is with visual glossaries of terms, definitions, and relationships.
Michael Herman, March 2021
Verifiable and Verifiable Data Registry are in the model but currently, they don’t have specific verified definitions.
Here’s a snapshot of what the TDW Glossary “all-in” view looks like today (aka the “network of balls connected by elastics”). The TDW Glossary has (or will very soon have) more than 500 terms and definitions plus associated metadata and relationships.
Thank you for the feedback, Leonard. Keep it coming.
Latest Version of the Proposal (0.2 – March 24, 2021)
Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call
OSI Stack Proposal for Confidential Storage Specification
1. Latest Version of the Proposal (0.2 – March 24, 2021)
From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net> Sent: March 24, 2021 4:14 PM To: sds-wg@lists.identity.foundation; Adam Stallard <adam.stallard@gmail.com>; Daniel Buchner (Personal) (danieljb2@gmail.com) <danieljb2@gmail.com>; Manu Sporny (msporny@digitalbazaar.com) <msporny@digitalbazaar.com>; Dmitri Zagidulin (dzagidulin@gmail.com) <dzagidulin@gmail.com> Cc: sds-wg@dif.groups.io; Credentials Community Group <public-credentials@w3.org>; Daniel Buchner <daniel.buchner@microsoft.com>; Chris Were (chris@verida.io) <chris@verida.io>; Orie Steele (orie@transmute.industries) <orie@transmute.industries> Subject: PROPOSAL: Confidential Storage Specification Refactoring 0.2 – March 24, 2021 – updated from version 0.1
PROPOSAL: Confidential Storage Specification Refactoring 0.2 – 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).
Version 0.2 adds some comments about inter-specification and specification version dependencies.
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.
EDV Specification 1.0: ZCAP/HTTP Data Vault Storage. The intent is for this specification to be fast-tracked based on the 3 existing prototype/PoC implementations. This specification would neither have nor take any dependencies on either of the 2 specifications below. In particular, this specification would neither have nor take any dependencies on the EDV Kernel Specification. A future version or variation of the EDV Specification may take a dependency against whatever is the current version of the EDV Kernel Specification – if the WG chooses to.
Data Hub Specification 1.0: Federated (or Aggregated) Personal Data Access. This specification would likely take a dependency against whatever is the current version of the EDV Specification (likely EDV Specification 1.0) – if the WG chooses to.
EDV Kernel Specification 1.0: Layer A Trusted Content Storage Kernel. This specification would not have nor take any hard dependencies against either of the above specifications. The EDV Kernel Specification would be guided by the needs/requirements of the prevailing EDV Specification 1.0: ZCAP/HTTP Data Vault Storage implementations in addition to the Fully Decentralized Twitter (Dewitter) user scenario. Ideally, Layer A of one of the prevailing implementations may act as the reference implementation for the EDV Kernel Specification (assuming its source code and documentation are freely licensed and open-sourced).
Best regards, Michael Herman Far Left Self-Sovereignist Self-Sovereign Blockchain Architect Trusted Digital Web Hyperonomy Digital Identity Lab Parallelspace Corporation
2. Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
From: Michael Herman (Trusted Digital Web) Sent: March 24, 2021 8:03 AM To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; sds-wg@lists.identity.foundation; sds-wg@dif.groups.io; Credentials Community Group <public-credentials@w3.org>; Daniel Buchner <daniel.buchner@microsoft.com> Subject: (Updated) Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
After relistening to the March 11 recording with more intent and building the partial transcription (see my previous email), I’ve come up with an updated architecture reference model (ARM) for this Agent-Hub-EDV stack that is emerging. Here’s a snapshot as of a few minutes ago…
Figure 2. Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
Michael
3. Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call
This is a transcription of selected parts of the EDV-Hub conversation during the DIF SDS/CS Thursday weekly Zoom call on March 11, 2021. This is the call where Daniel Buchner described (verbally) several aspects about what is and what is not a Hub.
This partial transcription focuses primarily on Daniel’s comments as they relate to the question “what is a Hub?”.
Have a great day, afternoon, or evening,
Michael
4. OSI Stack Proposal for Confidential Storage Specification
I tweaked (twerked?) up a version of https://commons.wikimedia.org/wiki/File:Osi-model-jb.svg to produce this …just an idea. It follows from a transcription of DanielB’s March 11 description of a Hub and where it sits between an Agent and an EDV.
Your thoughts? …maybe this becomes a key aspect/contribution in our CS specifications?
Figure 4. OSI Stack Proposal for Confidential Storage Specification
Best regards, Michael Herman Far Left Self-Sovereignist Self-Sovereign Blockchain Architect Trusted Digital Web Hyperonomy Digital Identity Lab Parallelspace Corporation
The SOVRONA Mesh is comprised of a network of SOVRONA Nodes (each hosting its own replica of the SOVRONA Ledger) and includes and is governed by the SOVRONA Governance Framework (SGF). The SOVRONA Mesh excludes the Agents that communicate with the SOVRONA Mesh via the HyperLedger Indy Service Endpoint exposed by each SOVRONA Node.
Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call: Hub and EDV Discussion featuring Daniel Buchner’s Description of a Hub
Context
This is a transcription of selected parts of the EDV-Hub conversation during the DIF SDS/CS Thursday weekly Zoom call on March 11, 2021. This is the call where Daniel Buchner described (verbally) several aspects about what is and what is not a Hub.
This partial transcription focuses primarily on Daniel’s comments as they relate to the question “what is a Hub?”.
NOTE: The time code timestamps are accurate but not precise. They may be out by +/- a couple of seconds.
28:35 Michael: What I was looking for is a litmus test. Oh yah, it goes in this bucket. Oh yah, it goes in that bucket. We don’t have that simple working definition – pair of working definitions – that easily contrasts the two.
29:40 Adrian: I’ve never felt I’ve understood Hubs in those terms.
30:14 Daniel: I think what a Hub is definitely not completely mutable by the user. It’s a standard interface for at a basic …
30:50 Daniel: What a Hub is really is a friendly application-level set of interfaces and functionality over an EDV that provides stuff like queuing up push-style messages to the owner of the Hub when they come online and go grab all of the outstanding objects. It allows people to store data by semantic type so that I can say here’s my Tweet objects [31:12 Daniel continuing], here’s my list objects, here’s playlist objects, and be able to give permissions in capability form out to people to see and decrypt parts of those objects.
So, this is what it is in a nutshell. An EDV is a great thing but you have to answer the question as Michael did in his paper with Twitter. Can you build Twitter off of just the EDV API elegantly, maybe you could torture yourself to do it but could you build it elegantly, would it be something [31:42 Daniel continuing] that speaks to app developers – probably not. You need a layer that is more app-focused…in my opinion.
32:10 Daniel: A Hub was always designed to be a rather dumb datastore. It’s not trying to do complex data transformations. [32:16 Daniel continuing] It’s a semantic searchable store of data that you can get permissions to certain subsets of the data as an app asking Alice for those permissions. [32:27 Daniel continuing] An Agent is very much more powerful. An Agent is actually pulling data down, decrypting it, doing a bunch of things. [32:35 Daniel continuing] I would see a Hub like an application datastore that is yours. That you allow apps to store data for you or other people. You can have one living on a local device; you could have one in the cloud. You could have an instance in several places and they all can sync together and even though they are implemented differently by a cloud provider (like Microsoft), they would have all the same APIs and guarantees because it is a standard. That’s how I envision it.
33:00 Michael: So, does the Hub’s datastore wrap or build upon on an EDV? …or is it completely like left vs. right?
33:01 Daniel (in chat): A Hub is a gateway/router between apps and EDVs.
33:10 Daniel: If you read that post that Orie posted in the chat. It is really great that he referenced that. [33:16 Daniel continuing] A Hub is essentially a layer that …
33:20 Daniel: We hoping that at the end of this, a Hub can sit above an EDV is where the EDV is where everything is encrypted and a sort of level-level thing. The Hub is like the application-style interface. Maybe like the Firebase API that speaks internally to store encrypted objects in a low-level way with the EDV.
33:31 Orie (in chat): EDV <> Hub <> Agent
33:37 Daniel: Orie is absolutely right but I would probably reverse the order. An Agent is super powerful; a Hub is less powerful; an EDV is very low-level storage and it is sort of like a Hub is the app layer that sits on top of an EDV …hopefully.
47:32 Daniel (in chat): It is a semantically indexed datastore, of which it can only see truly public data
52:17 Michael (in chat): Hub = intelligent public service endpoint … for EDV data
52:31 Daniel (in chat): YES!
52:39 Daniel (in chat): slightly intelligent
53:02 Daniel (in chat): only in the sense that it can layer some semantic APIs over the internal public objects.
Hyperonomy Digital Identity Lab™ - hyperonomy.com 
