Net Uptime Monitor (NUM)

The Net Uptime Monitor


What it does…


Is your internet connection unreliable? You’ve probably called your internet provider’s support line and maybe they were able to help you, maybe they even sent out a tech to look at it. But all too often the response is “Well, it’s working fine now!”


The Net Uptime Monitor alerts you to failures in your internet connection and documents the exact time and length of those failures. This failure log will help your provider troubleshoot the problem – after it helps you convince them it’s not your imagination! Net Uptime Monitor is designed to be as simple as possible and accomplish this one purpose accurately and thoroughly with the least effort from you.


How it works…


Net Uptime Monitor (NUM) uses the “Ping” command to test the response from three public servers operated by Google, Level 3, and OpenDNS. (See “What’s a Ping?” below for an explanation.) Each server is pinged in turn at an interval that you can set – normally five seconds. By default, NUM waits 200 milliseconds (2/10 of a second) for the server to respond – at least 3 times as long as a typical broadband internet connection should take.


NUM pings one server at a time; if the server responds, NUM waits the test interval, then pings the next server. If the server doesn’t respond, NUM immediately tries the next server, then the next. If any of the servers respond, then your connection must be working. Only when all three servers fail to respond does NUM determine that your connection is down.


By using three servers, NUM ensures that the problem isn’t just with the server or with some connection on the way to that server, or that the server isn’t momentarily slow or congested.


NUM can detect failures as short as a couple of seconds in length, but you can decide how long a failure must be before it really counts. A very short failure of a second or so is not likely to affect your use of the net and isn’t of any real concern. You can set how long a failure must be before NUM alerts you to it and records the failure in its failure log.


Connection is up, no previous failures…

Connection is down, one previous failure…

The display shows the names and IP addresses of each server. The indicator “light” flashes yellow when the ping is sent and shows green for a successful response. The response time of the last ping is shown. When the response time exceeds the time set for “Wait for Ping Response”, the indicator turns red to show no response from that server.


If your connection fails, the current fail length is displayed in red. When the length of the failure exceeds your setting for “Log Failure If Longer Than”, NUM plays an alert sound and writes the failure information into its log.


The display also shows the monitored time (how long the monitor has been running), the time since the last logged failure (up time), the start time and length of the last logged failure, and the total count of logged failures since NUM was started. The current settings for the test interval and the minimum failure length to be logged are shown at the bottom of the display.


Click the minimize button on the NUM window to hide the display. NUM disappears into your system tray in the “notifications area”. The NUM icon is shown in the notification – you can hover over the icon to see the current time since the last failure (“Up Time”) or click the icon to restore the display. In the Settings, you can choose to have a “failure alert” sound play, and/or have the NUM window “pop up”, if a connection failure longer than your minimum setting occurs.


The Log


NUM keeps a log of results in a text file. You can view the current log at any time by clicking the “View Log” button. The log is displayed in a separate window. NUM will continue to update the log even while you are viewing it.
Because the log is a plain text file, you can open it outside of the NUM program. It will open in Notepad or your default text editor, so you can easily edit or print the log.


The log records the start and end time of the monitoring and each failure start time and length. A summary shows the total monitoring time, failure count, total down time, percentage of down time, and the minimum, maximum, and average failure lengths. Here’s an example:

Net Uptime Monitor Failure Log (NetUptimeMonitor.com)
Licensed to Example User

=======================================

8/17/2015 8:44:28 AM Log Start

Failure Start Length
8/17/2015 1:44:25 PM 0:00:44
8/17/2015 1:49:53 PM 0:00:36

8/17/2015 1:52:39 PM 0:01:59

8/18/2015 12:13:17 AM Log End
Monitor Duration 15:28:46
Failure Summary:
Count 3
Total Downtime 0:03:20
% Downtime 0.36
Minimum Length 0:00:36
Maximum Length 0:01:59

Average Length 0:01:06

The example shows date and time in US English format; your log will use the format for your region.
The log files are saved in a folder of your choice; the default is your Documents folder. You can choose a different folder in the Settings.


Also in the Settings, there are two options for the log file:
1) New File Each Run
A new file is created each time NUM starts. Each log file is named with the date and time NUM was started so that they will appear in your directory in chronological order. The file name is in the form of “NetUptime 20110805 134243.txt”. In this example, the date is August 10, 2015 – 20150810 – and the time is 1:42:43 PM – 134243.
2) Add to Existing File
Each new log is added to the same single file. The file name is always NetUptime.txt. As long as that file exists in the folder where you have chosen to save the log file, NUM will keep adding to it. If the file doesn’t exist, i.e. it’s been deleted, moved, or renamed, NUM will start a new file.


The Settings

Click the “Change Settings” button on the NUM display to open the Settings window. There are several settings available:


Startup Settings…


· Start when Windows Starts? – Check the box and NUM will automatically start when your computer starts. Uncheck the box and you can start NUM when you want by clicking its desktop icon. The default on installation is checked – NUM starts automatically.
· Start Minimized in Tray? – Check the box and NUM will be minimized in the system tray automatically when it starts. The default on installation is unchecked – NUM starts with the main form displayed.
Test Settings…
· Test Interval – how many seconds between ping tests when the servers are responding. Five seconds is the default. It is possible that NUM will miss a failure that is shorter than the time between tests, so if your connection has very frequent failures of just a few seconds you might choose a shorter test interval. If you don’t have many failures, you may want to test less often. Most connection problems result in less frequent but longer failures, so five seconds is a good choice for most users.
· Wait for Ping Response – the length of time NUM waits for a response after sending a ping. The default setting of 200 milliseconds is recommended for normal situations. If you have a slower internet connection, such as a dialup or mobile connection, or are in a remote area where response is typically slow, you can set the wait time for up to 1500 milliseconds (1.5 seconds). To help you find the best setting for your situation, set the wait time to 1500 milliseconds and observe the ping response times NUM displays when your connection is working normally. Set the wait time to about 1.5 times the typical ping response times you see for efficient detection of outages.
· Change Target Servers – click to open the Target Servers window.

You can edit the IP Address and Name of any of the three servers. Click the Test button to try that server, verifying that it responds and checking the response time.


The default target servers (Google, Level 3, OpenDNS) were selected for their performance and very high reliability. You should only use a different server if you find that one of these servers does not respond reliably in your particular situation. Click “Restore Defaults” to reset the Target Servers to their original values. Changes to the Target Servers take effect the next time the program starts.


Alert and Log Settings…


· Pop Up on Failure? – Check the box and the NUM form will pop up from the system tray when there is a failure. Uncheck the box and NUM will continue to log and alert but it will stay minimized during a failure. The default on installation is checked – if NUM is minimized to the system tray, the main NUM form will be displayed when a failure is logged.
· Alert and Log Failure If Longer Than – the minimum failure length that will be counted, both for the log and the alert of a failure. Five seconds is the default setting.
· Log File Location – the folder where the logs will be stored. Click the “Select Folder” button to browse to the folder you want. The log for the current run of NUM is already started, so a change in this setting will not take effect until the next time you run NUM.
· Log File Option – New File Each Run (the default) or Add to Existing File. See previous section “The Log” for a more detailed explanation.
· Choose Failure Alert Sound – choose the sound NUM makes when a failure is counted. The sound plays when you choose its button so you can preview each one. Choose “None” to silence the alert. Choose “Custom” and click the Select File button to use any .WAV sound file on your system. The default on installation is the “Short” sound.
· Play Reconnect Sound – NUM can play a sound when your internet reconnects after a failure. Choose “None” to silence the reconnect sound. Choose “Custom” and click the Select File button to use any .WAV sound file on your system.


Combine Settings for “Invisible” Operation


NUM can do its job without showing itself or alerting the user to its operation in any way. Choose these settings:
· Start when Windows Starts? – checked.
· Start Minimized in Tray? – checked.
· Pop Up On Failure – unchecked.
· Choose Failure Alert Sound – None.
· Choose Reconnect Sound – None.
With this combination of settings, the user need never be aware of NUM. This is useful in a support situation where you are installing NUM on a computer you aren’t personally using.


What’s a Ping?


“Ping” is a command available on all kinds of computers that tests whether another computer on the network will respond to your computer. It’s named after the sound of submarine sonar systems – they send out a “ping” sound which bounces off their target and they listen for that echo, locating their target. The internet “ping” works in a similar way. You name your target, an internet server, and “ping” it. The ping command and response looks like this (in a DOS command window):


C:\ ping google.com

Pinging google.com [74.125.224.84] with 32 bytes of data:
Reply from 74.125.224.84: bytes=32 time=30ms TTL=54
Reply from 74.125.224.84: bytes=32 time=31ms TTL=54
Reply from 74.125.224.84: bytes=32 time=31ms TTL=54
Reply from 74.125.224.84: bytes=32 time=31ms TTL=54

Ping statistics for 74.125.224.84:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 31ms, Average = 30ms

A ping command actually generates four requests and the server replies four times. Each response is timed in thousandths of a second (ms = milliseconds). Here we see that the server at google.com responded in about 31/1000 or 3/100 of a second. The internet is fast! – when everything’s working.


Licensing


A license for Net Uptime Monitor removes the time limits from the trial version and lets you use the full program on one computer. To purchase a license or register your license, just click “Trial Version – Click to Register or Purchase License” at the bottom of the NUM main form. If you have your license, enter the License Key code you’ve received and click Register. If you need a license, click Purchase a License to visit our web site and make your purchase.
If you have already registered your copy of NUM, your name and email are shown on the main form. Click the License Info button to see your license key.


Moving to a New Computer or Installing a New Operating System


You must unregister your license before you replace your computer or install a new version of Windows. This will make your license key available again to use on your new system. Just click License Info, click Print This Form to make sure you’ll have the license key, then click Unregister License. The program will go back to Trial mode. You can then reuse your license key to register NUM on any computer.

Leave a comment

Filed under Uncategorized

NETAGO Downtime – 2021-05-11 – 93%

Net Uptime Monitor Failure Log (NetUptimeMonitor.com)
Licensed to Michael Herman

=======================================

2021-05-11 7:03:07 AM Log Start

Failure Start Length
2021-05-11 7:03:38 AM 0:00:46
2021-05-11 7:06:43 AM 0:00:05
2021-05-11 7:07:43 AM 0:02:57
2021-05-11 7:10:49 AM 0:36:32
2021-05-11 7:47:29 AM 0:05:17
2021-05-11 7:53:40 AM 0:07:14
2021-05-11 8:01:02 AM 0:01:42
2021-05-11 8:02:53 AM 0:03:00
2021-05-11 8:06:01 AM 0:00:50
2021-05-11 8:07:18 AM 0:02:56
2021-05-11 8:10:23 AM 0:06:16
2021-05-11 8:17:07 AM 0:06:48
2021-05-11 8:24:49 AM 0:02:43
2021-05-11 8:27:40 AM 0:05:36
2021-05-11 8:33:50 AM 0:00:24
2021-05-11 8:35:28 AM 0:10:01
2021-05-11 8:46:23 AM 0:21:58
2021-05-11 9:09:15 AM 0:13:49
2021-05-11 9:23:39 AM 0:02:06
2021-05-11 9:28:10 AM 0:06:14
2021-05-11 9:35:57 AM 0:12:14
2021-05-11 9:49:11 AM 0:02:55
2021-05-11 9:53:13 AM 0:10:16
2021-05-11 10:03:43 AM 0:07:44
2021-05-11 10:13:39 AM 0:00:24
2021-05-11 10:16:27 AM 0:03:55
2021-05-11 10:20:56 AM 0:07:14
2021-05-11 10:28:24 AM 0:00:20
2021-05-11 10:28:53 AM 0:00:11
2021-05-11 10:29:13 AM 0:00:11
2021-05-11 10:30:11 AM 0:00:41
2021-05-11 10:31:20 AM 0:01:01
2021-05-11 10:32:48 AM 0:06:12
2021-05-11 10:40:07 AM 0:01:14
2021-05-11 10:41:29 AM 0:04:03
2021-05-11 10:46:00 AM 0:08:14
2021-05-11 10:55:34 AM 0:03:37
2021-05-11 11:00:56 AM 0:01:54
2021-05-11 11:03:05 AM 0:06:05
2021-05-11 11:09:38 AM 0:14:24
2021-05-11 11:25:15 AM 0:00:15
2021-05-11 11:25:38 AM 0:04:01
2021-05-11 11:30:08 AM 0:00:25
2021-05-11 11:31:28 AM 0:03:26
2021-05-11 11:35:08 AM 0:03:37
2021-05-11 11:39:33 AM 0:01:45
2021-05-11 11:41:32 AM 0:05:13
2021-05-11 11:47:20 AM 0:16:20
2021-05-11 12:05:19 PM 0:18:31
2021-05-11 12:24:11 PM 0:12:56
2021-05-11 12:37:15 PM 0:08:06
2021-05-11 12:45:30 PM 0:01:18
2021-05-11 12:48:01 PM 0:01:58
2021-05-11 12:50:08 PM 0:05:59
2021-05-11 12:56:15 PM 0:29:48
2021-05-11 1:26:18 PM 0:06:12
2021-05-11 1:32:45 PM 0:16:43
2021-05-11 1:49:43 PM 0:00:11
2021-05-11 1:50:02 PM 0:32:03
2021-05-11 2:22:13 PM 0:17:54
2021-05-11 2:40:41 PM 0:00:06
2021-05-11 2:40:55 PM 0:16:30
2021-05-11 2:59:04 PM 0:00:54
2021-05-11 3:01:44 PM 0:01:18
2021-05-11 3:03:10 PM 0:18:05
2021-05-11 3:21:36 PM 0:01:21
2021-05-11 3:23:51 PM 0:10:10
2021-05-11 3:34:10 PM 0:03:28
2021-05-11 3:39:16 PM 0:06:33
2021-05-11 3:46:24 PM 0:16:42
2021-05-11 4:03:14 PM 0:19:54
2021-05-11 4:25:39 PM 0:12:58
2021-05-11 4:40:09 PM 0:04:53
2021-05-11 4:45:10 PM 0:01:45
2021-05-11 4:47:03 PM 0:06:46
2021-05-11 4:53:58 PM 0:01:08
2021-05-11 4:55:14 PM 0:38:56
2021-05-11 5:34:25 PM 0:13:51
2021-05-11 5:48:30 PM 0:35:29
2021-05-11 6:26:18 PM 0:01:45
2021-05-11 6:28:17 PM 0:09:13
2021-05-11 6:37:45 PM 0:01:16
2021-05-11 6:39:10 PM 0:01:36
2021-05-11 6:42:25 PM 0:34:53
2021-05-11 7:17:27 PM 0:08:36
2021-05-11 7:26:37 PM 0:15:57
2021-05-11 7:42:43 PM 0:04:15
2021-05-11 7:47:06 PM 0:35:10
2021-05-11 8:22:37 PM 0:09:37
2021-05-11 8:32:23 PM 0:13:20

2021-05-11 8:45:51 PM 0:24:59

2021-05-11 9:10:58 PM Log End
Monitor Duration 14:07:50
Failure Summary:
Count 91
Total Downtime 13:08:53
% Downtime 93.05
Minimum Length 0:00:05
Maximum Length 0:38:56

Average Length 0:08:40

Leave a comment

Filed under Uncategorized

The Verifiable Economy Architecture Reference Model (VE-ARM): Fully Decentralized Object (FDO) Model

Michael Herman
Hyperonomy Digital Identity Lab
Trusted Digital Web Project
Parallelspace Corporation

NOTE: This article supersedes an older version of this article:

1. Introduction

1.1 Goals

The goals of this article are three-fold:

  1. Introduce the concept of a Verifiable Capability Authorizations (VCA) and how they can be used to implement controls over which specific methods a particular party is allowed to execute against a particular instance of a Fully Decentralized Object (FDO). VCAs are both delegatable and attenuatable.
  2. Illustrate how #graphitization techniques can be used for modeling and visualizing:
    • Trusted Decentralized Identifiers (DIDs)
    • DID Documents
    • Trusted Digital Agents (and their Service Endpoints (SEPs))
    • Verifiable Credentials (VCs)
    • Verifiable Capability Authorizations (VCAs) and,
    • Most importantly, their myriad of interrelationships.
  3. Use the above 2 goals to further detail and describe how to use the VE-ARM model for implementing trusted, reliable, efficient, frictionless, standards-based, global-scale software systems based on Fully Decentralized Objects (FDOs).

1.2 Purpose

This article takes the following “All-in” graph view of The Verifiable Economy Architecture Reference Model (VE-ARM) and partitions it into a series of subgraphs that depict the key elements of the overall architecture reference model for FDOs. Each subgraph is documented with a narrative that is mapped to the numbered blue targets used to identify each element in each subgraph.

Figure 1. Subgraph 0. The Verifiable Economy Architecture Reference Model (VE-ARM)

The above graphitization is the result of a several iterations validating The Verifiable Economy Architecture Reference Model (VE-ARM) against the following live scenario:

Erin acquiring a personal DID and DID Document to enable Erin to acquire a Province of Sovronia Driver’s License (SDL) (represented as an FDO) and hold the SDL in Erin’s digital wallet.

TDW Glossary: Self-Sovereign Identity (SSI) User Scenarios: Erin Buys a Car in Sovronia (3 User Scenarios)

A Fully Decentralized Object (FDO) is comprised of the following minimal elements:

  1. DID (and correspond DID Document)
  2. Master Verifiable Capability Authorization (MVCA) for the object’s DID and DID Document
  3. Zero or more Verifiable Capability Authorizations (VCAs) linked to the above MVCA for the object (recursively)
  4. A Property Set for the FDO
    • Property Set DID (and corresponding DID Document)
    • Property Set MVCA that is issued when the Property Set’s DID and DID Document is issued.
    • Property Set Verifiable Credential (VC) is issued to hold the object’s properties and their values
    • Zero or more Verifiable Capability Authorizations (VCAs) linked to the FDO’s Property Set MVCA (recursively)
  5. A Trusted Digital Agent registered with a Service Endpoint (SEP) in the object’s DID Document that implements the VCA-controlled methods for accessing and interacting with the object and/or it’s property set. Control over which methods are invokable by a party is controlled by the respective MVCAs and a Delegated Directed Graphs of VCAs (if there are any).

The goal and purpose of the VE-ARM is to describe a Fully-Decentralized Object (FDO) model that unites the following concepts into a single integrated, operational model:

  • Verifiable Identifiers, Decentralized Identifiers (DIDs), and DID Documents;
  • Verifiable Claims, Relationships, and Verifiable Credentials (VCs);
  • Master Verifiable Capability Authorizations (MVCA) (Master Proclamations), Verifiable Capability Authorizations (VCAs) (Proclamations), Verifiable Capability Authorization Method Invocations (MIs); and
  • Trusted Digital Agents (TDAs).

1.3 Background

The scenario used to model the VE-ARM is an example of a citizen (Erin) of a fictional Canadian province called Sovronia holding a valid physical Sovronia Driver’s License (Erin RW SDL) as well as a digital, verifiable Sovronia Driver’s License (Erin SDL).

Figure 2. Erin’s “Real World” Sovronia Driver’s License (Erin RW SDL)

1.4 Graphitization of the Verifiable Economy Architecture Reference Model (VE-ARM)

The underlying model was built automatically using a series of Neo4j Cypher queries running against a collection of actual DID Document, Verifiable Credential, and Verifiable Capability Authorization JSON files. The visualization was laid out using the Neo4j Browser. The resulting layout was manually optimized to produce the final version of the graphitization used in this article. The numbered targets used to identify each element in each subgraph were added using Microsoft PowerPoint.

2. Organization of this Article

Following a list of Key Definitions, the remainder of this article is organized as a series of increasingly more detailed explanations of the VE-ARM model. The overall model is partitioned into a collection of (overlapping) subgraphs.

Each subgraph is described by a narrative that explains the purpose of each element in the particular subgraph. Each narrative is organized as a list of numbered bullets that further describe to the corresponding numbered blue targets used to identify each element in each subgraph .

A narrative is a story. It recounts a series of events that have taken place. … These essays are telling a story in order to drive a point home. Narration, however, is the act of telling a story.

Examples of Narration: 3 Main Types in Literature

2.1 Table of Subgraphs

  • Subgraph F1 – Erin’s DID Document (DD) Neighborhood
  • Subgraph F2 – Erin’s DD Master Verifiable Capability Authorization (MVCA) Neighborhood
  • Subgraph F3 – Province of Sovronia DID Document (DD) Neighborhood
  • Subgraph F4 – Province of Sovronia DD Master Verifiable Capability Authorization (MVCA) Neighborhood
  • Subgraph F5 – DID Documents (DDs) and Master Verifiable Capability Authorizations (MVCAs) Neighborhood
  • Subgraph F6 – Erin’s Sovronia Drivers License (SDL) Property Set Verifiable Credential (VC) Neighborhood
  • Subgraph F7 – Erin’s SDL Property Set Delegated Directed Graph of Verifiable Capability Authorizations Neighborhood
  • Subgraph F8 – Erin “Real World” Neighborhood
  • Subgraph F9 – SOVRONA Trusted Decentralized Identity Provider (TDIDP) Neighborhood
  • Subgraph F10 – The Verifiable Economy “All-In” Graph View
Figure 4. Subgraph 0. Table of Subgraphs

3. Key Definitions

Several of the following definitions (those related to the concept oferifiable capability authorizations) are inspired by the following RWoT5 article:

Additional context can be found in Authorization Capabilities for Linked Data v0.3.

3.1 VE-ARM Verifiable Capability Authorization (VCA) Model

The VE-ARM Verifiable Capability Authorization (VCA) model used to grant the authority to specific parties to invoke specific methods against an instance of a Fully Decentralized Object (FDO). The VE-ARM VCA model is based, in part, on the Object-Capability Model. The VE-ARM VCA model supports Delegation and Attenuation.

3.2 Object Capability Model

The object-capability model is a computer security model. A capability describes a transferable right to perform one (or more) operations on a given object. It can be obtained by the following combination:

– An unforgeable reference (in the sense of object references or protected pointers) that can be sent in messages.
– A message that specifies the operation to be performed.

Object-Capability Model (https://en.wikipedia.org/wiki/Object-capability_model)

3.3 VCA Model Principles Delegation and Attenuation

With delegation, a capability holder can transfer his capability to another entity, whereas with attenuation he can confine a capability before delegating it.

Capability-based access control for multi-tenant systems using OAuth 2.0 and Verifiable Credentials

3.4 Fully Decentralized Object (FDO)

In The Verifiable Economy, a Fully Decentralized Object (FDO) is comprised of the following minimal elements:

  1. DID (and correspond DID Document)
  2. Master Verifiable Capability Authorization (MVCA) for the object’s DID and DID Document
  3. Zero or more Verifiable Capability Authorizations (VCAs) linked to the above MVCA for the object (recursively)
  4. A Property Set for the FDO
    • Property Set DID (and corresponding DID Document)
    • Property Set MVCA that is issued when the Property Set’s DID and DID Document is issued.
    • Property Set Verifiable Credential (VC) is issued to hold the object’s properties and their values
    • Zero or more Verifiable Capability Authorizations (VCAs) linked to the FDO’s Property Set MVCA (recursively)
  5. An Trusted Digital Agent registered with a Service Endpoint (SEP) in the object’s DID Document that implements the VCA-controlled methods for accessing and interacting with the object and/or it’s property set. Control over which methods are invokable by a party is controlled by the respective MVCAs and a Delegated Directed Graphs of VCAs (if there are any).

3.5 Fully Decentralized Object (FDO) Model

A complete decentralized object system based on the concept of FDOs.

3.6 Verifiable Capability Authorization (VCA)

A Verifiable Capability Authorization (VCA) is a JSON-LD structure that grants (or restricts) a specific party (the controller of a key (grantedKey)) the ability to invoke specific methods against a specific instance of a Fully Decentralized Object (FDO). A VCA typically has a type of Proclamation (unless it is a Method Invocation VCA).

A VCA has the following properties:

  • id – trusted, verifiable decentralized identifier for the VCA
  • type – “Proclamation”
  • parent – trusted, verifiable decentralized identifier for a parent VCA whose control supersedes this current VCA.
  • subject – trusted, verifiable decentralized identifier of the specific instance of the FDO.
  • grantedKey – trusted, verifiable key of the party to whom the specified capabilities are being granted specifically with respect to the specific instance of the FDO.
  • caveat – the collection of specific capabilities the party represented by grantedKey is granted (or restricted) from invoking against a specific instance of the FDO identified by the subject identifier.
  • signature – trusted, verifiable proof that this VCA is legitimate.

NOTE: The current VCA’s capabilities must be equal to or an attenuation of the parent VCA’s capabilities. This part of the VCA model is recursive.

NOTE: An FDO can be an object or a service represented as an object.

The following is an example of a VCA associated with Erin and Erin’s Sovronia Driver’s License Property Set.

Snippet 1. Verifiable Credential Authorization (VCA) Example

3.7 Master Verifiable Capability Authorization (MVCA)

A Master Verifiable Capability Authorization (MVCA) is a Proclamation-type VCA that is created for every FDO at the time that the DID and DID Document for the FDO is issued by a Trusted Decentralized Identity Provider (TDIDP) (e.g. SOVRONIA).

That is, a new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA typically grants authorization for any and all methods to the controller of the DID. (This is the essence of the definition of self-sovereign identity principle.)

An MVCA has the following properties:

  • id – trusted, verifiable decentralized identifier for the VCA
  • type – “Proclamation” (or “Invocation”)
  • subject – trusted, verifiable decentralized identifier of the specific instance of the FDO. An FDO can be an object or a service represented as an object.
  • grantedKey – trusted, verifiable key of the party to whom the specified capabilities are being granted specifically with respect to the specific instance of the FDO.
  • caveat – the collection of specific capabilities the party represented by grantedKey is granted (or restricted) from invoking against a specific instance of the FDO identified by the subject identifier. Typically, this is set to RestrictToMethod( * ) granting the controller of the grantedKey to execute any and all methods against the subject. (This is where and how the essence of the definition of the self-sovereign identity principle is realized.)
  • signature – trusted, verifiable proof that this VCA is legitimate.

NOTE: A MVCA has no parent property because an MVCA always represents the top-level root VCA in a Delegated Directed Graphs of Verifiable Capability Authorizations (see below).

The following is an example of a MVCA for Erin’s Sovronia Drivers License Property Set. This MVCA is the parent of the above VCA.

Snippet 2. Master Verifiable Credential Authorization (MVCA) Example

3.8 VCA Method Invocation (MI)

A VCA Method Invocation (MI) is a JSON-LD structure that attempts to invoke a specific method against a specific instance of a Fully Decentralized Object (FDO) on behalf of a specific invoking party. An MI is of type Invocation (not Proclamation).

An MI has the following properties:

  • id – trusted, verifiable decentralized identifier for the MI
  • type – “Invocation”
  • proclamation – trusted, verifiable decentralized identifier for the VCA to be used for this MI against the specific instance of an FDO by a specific party (Proclamation VCA).
  • method – specific name of the method to be invoked against the specific instance of an FDO by a specific party.
  • usingKey – trusted, verifiable key of the party to be used to attempt the invocation of the above method against a specific instance of the FDO.
  • signature – trusted, verifiable proof that this VCA is legitimate.

NOTE: An MI doesn’t have a subject property. The target object is specified by the subject property of the proclamation VCA.

A very important point you make is, “NOTE: An MI doesn’t have a subject property. The target object is specified by the subject property of the proclamation VCA.”  That point is so important, not separating designation from authorization, that I’d like to see it in bold.

Alan Karp alanhkarp@gmail.com, May 17, 2021 CCG Mailing List

The following is an example of a MI that attempts to invoke the Present method on behalf of Erin against Erin’s Sovronia Drivers License Property Set. The referenced VCA is the VCA example from above.

Snippet 3. Verifiable Credential Authorization Method Invocation (MI) Example

3.9 Delegated Directed Graph of Verifiable Capability Authorizations

A Delegated Directed Graph of Verifiable Capability Authorizations is a directed list of VCAs that starts with an MVCA as it’s top-level, root VCA. Each VCA in the graph points to the previous VCA in the graph via its parent property. An MI, in turn, refers to a single VCA in the graph via the MI’s proclamation property. The capabilities in effect are those that are specifically listed in the target VCA’s caveat property. While there is no inheritance of capabilities in this model, the capabilities specified by each VCA must be equal or less than (a subset of) the capabilities of the parent VCA (see the definition of Principles of Delegation and Attenuation).

The above examples of an MVCA, a VCA, and an MI, taken together, form an example of a Delegated Directed Graph of Verifiable Capability Authorizations.

Figure 3. Delegated Directed Graph of Verifiable Capability Authorizations Example

3.8.1 Narrative

17. Erin SDL Prop Set MVCA. Erin SDL Prop Set MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL Prop Set (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

18. Erin SDL VCA. Erin SDL VCA is the Verifiable Capability Authorization (VCA) created for Erin’s SDL Prop Set DD. The VCA was issued by the Province of Sovronia authorizing Erin to be able to present the properties (and their values) of Erin’s SDL to a third party using the Present method associated with Erin’s SDL Prop Set and supported (implemented) by Erin’s AGENT. The parent of Erin’s SDL VCA is the Erin SDL MVCA.

19. Erin SDL VCA MI. Erin SDL VCA MI is an example of a MVCA Method Invocation (VCA MI) that uses the Erin SCL VCA which authorizes the potential execution of the Present method by Erin against Erin’s SDL Prop Set.

3.10 Resource Servers and Authentication Servers

A resource server that hosts a protected resource owned by a resource owner, a client wishing to access that resource, and an authorization server responsible for generating access tokens. Access tokens are granted to clients authorized by the resource owner: client authorization is proven using an authorization grant. In our system we are using the ‘client credentials’ grant. As it can be seen from Fig. 1, when this type of grant is used, a resource owner configures the authentication server with the credentials of the authorized clients; a client authenticates to the authorization server and receives an access token, then it uses the access token to access the protected resource.

Capability-based access control for multi-tenant systems using OAuth 2.0 and Verifiable Credentials

Although these terms are not currently used in the VE-ARM, the resource server role is assigned to the FDO AGENT specified in the subject’s DID document. The authorization server role is assigned to the actor who is responsible for creating Verifiable Capability Authorizations (VCAs). In the current example, SOVORONIA hosts the authorization server on behalf of either the Province of Sovronia or Erin.

4. VE-ARM Principles

The following principles are used to guide The Verifiable Economy Architecture Reference Model (VE-ARM):

  1. DD MVCA Principle. Every DID (and DID Document) has a corresponding Master Verifiable Capability Authorization (MCVA). Whenever a DID and corresponding DID Document is issued, a corresponding Master Verifiable Capability Authorization (MCVA) is automatically created. See F2 in Figure 1. Snippet 4 is an example of a DID Document Master Verifiable Capability Authorization (DD MVCA).
  2. Property Set VC Principle. All of the properties (and their values), a Property Set, for a particular decentralized object are stored in a Verifiable Credential (VC) that has an id value that is equal to the DID id of the decentralized object. See F6 in Figure 6. Snippet 5 is a partial example of a Property Set Verifiable Credential (PS VC).
Snippet 4. DID Document Master Verifiable Capability Authorization (MVCA) Example
Snippet 5. Partial Property Set Verifiable Credential (VC) Example

NOTE: Additional architecture and design principles need to be added to this section.

5. Erin’s DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhoods

Erin Amanda Lee Anderson is a Person, a Citizen of Sovronia, and a Sovronia Driver’s License holder. The following is a graphitization of Erin’s DID and DID Document and the corresponding Master Verifiable Capability Authorization (MVCA).

Figure 5. Subgraphs F1 and F2: Erin’s DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhoods

5.1 Erin’s DID Document Narrative (F1)

1. Erin. Erin is a RW_PERSON (“Real World” Person) and a citizen of the Province of Sovronia. Erin also holds a (valid) Sovronia Driver’s License (SDL) and controls a “Real World” Wallet (RW_WALLET) as well as a Digital Wallet (PDR).

2. Erin D Wallet. Erin D Wallet is a Digital Wallet (PDR (Private Data Registry)) controlled by Erin, a Person.

3. Erin DD. Erin DD is the primary DIDDOC (DID Document) for Erin, a Person. It is issued by SOVRONA who records it on the SOVRONA VDR and it is also held in the Erin DD Wallet.

4. DID:SVRN:PERSON:04900EEF-38E7-487E-8D6F-09D6C95D9D3E#fdom1. DID:SVRN:PERSON:04900EEF-38E7-487E-8D6F-09D6C95D9D3E#fdom1 is the identifier for the primary AGENT for Erin, a Person.

5. http://services.sovronia.ca/agent. http://services.sovronia.ca/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by the Province of Sovronia, an Organization. This includes all of the DID(s) and DID Document(s) associated with Erin.

6. SOVRONA VDR. SOVRONA VDR is the primary VDR (Verifiable Data Registry) controlled by SOVRONA, an Organization. The SOVRONA VDR is used to host the SVRN DID Method.

5.2 Erin’s DD Master Capability Authorization Narrative (F2)

7. Erin DD MVCA. Erin DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s DID Document at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods to Erin.)

6. Province of Sovronia DID Document (DD) and DD Master Verifiable Capability Authorization (MVCA) Neighborhood

Province of Sovronia is an Organization and a “Real World” Nation State (sovronia.ca). The following is a graphitization of the Province of Sovronia’s DID and DID Document and its corresponding Master Verifiable Capability Authorization (MVCA).

Figure 6. Subgraphs F3 and F4: Province of Sovronia DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhood

6.1 Province of Sovronia DID Document (DD) Narrative (F3)

6. SOVRONA VDR. SOVRONA VDR is the primary VDR (Verifiable Data Registry) controlled by SOVRONA, an Organization. The SOVRONA VDR is used to host the SVRN DID Method.

8. PoS RW Nation State. The Province of Sovronia is a (fictitious) Province (RW_NATIONSTATE (“Real World” Nation State)) in Canada and the legal government jurisdiction for the citizens of the province. The Province of Sovronia is an Organization. The Province of Sovronia issues “Real World” Sovronia Driver’s Licenses (SDLs) but relies on SOVRONA to issue digital, verifiable SDLs.

9. PoS D Wallet. PoS D Wallet is a Digital Wallet (PDR (Private Data Registry)) controlled by the Province of Sovronia, an Organization.

10. PoS DD. PoS DD is the primary DIDDOC (DID Document) for the Province of Sovronia, an Organization. It is issued by SOVRONA who records it on the SOVRONA VDR and it is held in the PoS D Wallet.

11. DID:SVRN:ORG:0E51593F-99F7-4722-9139-3E564B7B8D2B#fdom1. DID:SVRN:ORG:0E51593F-99F7-4722-9139-3E564B7B8D2B#fdom1 is the identifier for the primary AGENT for the Province of Sovronia, an Organization.

12. http://services.sovrona.com/agent. http://services.sovrona.com/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by SOVRONA, an Organization.

6.2 Province of Sovronia DD Master Capability Authorization Neighborhood (F4)

13. PoS DD MVCA. PoS DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for the Province of Sovronia’s DID Document (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of itself for the Province of Sovronia. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods to the Province of Sovronia.)

7. DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhoods

A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. This subgraph highlights that with every new DID and DID Document, a corresponding MVCA is issued at the same time. The graphitization includes all of the DIDs in the Subgraph 0 scenario (plus their corresponding MVCAs).

Figure 7. DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhoods

7.1 DID Documents (DDs) and Master Verifiable Capability Authorizations (MVCAs) Narratives (F5)

3. Erin DD. Erin DD is the primary DIDDOC (DID Document) for Erin, a Person. It is issued by SOVRONA who records it on the SOVRONA VDR and it is also held in the Erin DD Wallet.

7. Erin DD MVCA. Erin DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s DID Document at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods to Erin.)

10. PoS DD. PoS DD is the primary DIDDOC (DID Document) for the Province of Sovronia, an Organization. It is issued by SOVRONA who records it on the SOVRONA VDR and it is held in the PoS D Wallet.

13. PoS DD MVCA. PoS DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for the Province of Sovronia’s DID Document (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of itself for the Province of Sovronia. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods to the Province of Sovronia.)

14. Erin SDL DD. Erin SDL DD is the primary DIDDOC (DID Document) for Erin’s digital, verifiable SDL.

15. Erin SDL MVCA. Erin SDL MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

16. Erin SDL Prop Set DD. Erin SDL Prop Set DD is the primary DIDDOC (DID Document) for the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop Set, a Verifiable Credential associated with the DID in Erin SDL Prop Set DD.

17. Erin SDL Prop Set MVCA. Erin SDL Prop Set MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL Prop Set (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

8. Erin’s Sovronia Drivers License Property Set DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhood

Subgraph F6 illustrates how a Property Set for an FDO is realized by a Verifiable Credential (VC). The following is a graphitization of Erin’s Sovronia Driver’s License Property Set.

NOTE: All the properties of an FDO (an FDO Property Set) are represented by one or more Verifiable Credentials associated with the FDO’s DID. A Property Set is associated with an FDO by creating a Verifiable Credential that holds the properties (and their values) that is linked to the FDO’s DID.

VE-ARM Principles
Figure 8. Subgraphs F6. Erin’s Sovronia Drivers License Property Set DID Document (DD) and Master Verifiable Capability Authorization (MVCA) Neighborhood

8.1 Erin’s Sovronia Drivers License Property Set Verifiable Credential (VC) Narrative (F6)

16. Erin SDL Prop Set DD. Erin SDL Prop Set DD is the primary DIDDOC (DID Document) for the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop Set, a Verifiable Credential associated with the DID in Erin SDL Prop Set DD.

17. Erin SDL Prop Set MVCA. Erin SDL Prop Set MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL Prop Set (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

20. Erin SDL Prop Set VC. Erin SDL Prop Set VC is the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop Set VC, a Verifiable Credential associated with the DID in Erin SDL Prop Set DD.

9. Erin’s Sovronia Drivers License Property Set Delegated Directed Graph of Verifiable Capability Authorizations Neighborhood

This subgraph illustrates what a Delegated Directed Graph of Verifiable Capability Authorizations looks like. The graphitization of the Delegated Directed Graph of VCAs applies to Erin’s Sovronia Drivers License Property Set.

The Delegated Directed Graph of VCAs, in this scenario, consists of:

  • Erin’s Sovronia Drivers License Property Set MVCA
  • One VCA linked back to the MVCA
  • One VCA Method Innovation (MI) linked back the VCA
Figure 9. Subgraphs F7. Erin’s Sovronia Drivers License Property Set Delegated Directed Graph of Verifiable Capability Authorizations Neighborhood

9.1 Erin’s SDL Property Set Delegated Directed Graph of Verifiable Capability Authorizations Narrative (F7)

16. Erin SDL Prop Set DD. Erin SDL Prop Set DD is the primary DIDDOC (DID Document) for the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop Set, a Verifiable Credential associated with the DID in Erin SDL Prop Set DD.

17. Erin SDL Prop Set MVCA. Erin SDL Prop Set MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL Prop Set (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

18. Erin SDL VCA. Erin SDL VCA is the Verifiable Capability Authorization (VCA) created for Erin’s SDL Prop Set DD. The VCA was issued by the Province of Sovronia authorizing Erin to be able to present the properties (and their values) of Erin’s SDL to a third party using the Present method associated with Erin’s SDL Prop Set and supported (implemented) by Erin’s AGENT. The parent of Erin’s SDL VCA is the Erin SDL MVCA.

19. Erin SDL VCA MI. Erin SDL VCA MI is an example of a MVCA Method Invocation (VCA MI) that uses the Erin SCL VCA which authorizes the potential execution of the Present method by Erin against Erin’s SDL Prop Set.

10. SOVRONA Trusted Decentralized Identity Provider (TDIDP) DID Document (DD), DD Master Verifiable Capability Authorization (MVCA) and Erin “Real World” Neighborhoods

Subgraph F8 is a visualization of:

  1. Erin’s “Real World” objects
    1. Erin’s “Real World” Wallet (Erin RW (Leather) Wallet)
    2. Erin’s “Real World” Sovronia Drivers License (Erin RW SDL)
  2. SVORONIA’s DID and DID Document (and corresponding MVCA)
Figure 10. SOVRONA TDIDP DID Document (DD), DD Master Verifiable Capability Authorization (MVCA) and Erin “Real World” Neighborhoods

10.1 Erin’s “Real World” Narrative (F9)

1. Erin. Erin is a RW_PERSON (“Real World” Person) and a citizen of the Province of Sovronia. Erin also holds a (valid) Sovronia Driver’s License (SDL) and controls a “Real World” Wallet (RW_WALLET) as well as a Digital Wallet (PDR).

8. PoS RW Nation State. The Province of Sovronia is a (fictitious) Province (RW_NATIONSTATE (“Real World” Nation State)) in Canada and the legal government jurisdiction for the citizens of the province. The Province of Sovronia is an Organization. The Province of Sovronia issues “Real World” Sovronia Driver’s Licenses (SDLs) but relies on SOVRONA to issue digital, verifiable SDLs.

22. Erin RW Wallet. Erin RW Wallet is a RW_WALLET (“Real World” (Leather) Wallet) and it is used to hold Erin’s “Real World” Sovronia Driver’s License (Erin RW SDL). Erin RW Wallet is owned and controlled by Erin.

23. Erin RW SDL. Erin RW SDL is Erin’s RW_SDL (“Real World” Sovronia Driver’s License) and it is held by Erin in Erin’s RW Wallet.

10.2 SOVRONA TDIDP Narrative (F10)

12. http://services.sovrona.com/agent. http://services.sovrona.com/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by SOVRONA, an Organization.

24. SOVRONA Organization. SOVRONA is an Organization and the primary “Real World” TDIDP (RW_DIDPROVIDER) for the citizens and government of Sovronia, a fictitious province in Canada. SOVRONA controls a Digital Wallet (PDR (Personal Data Registry)), SOVRONA D Wallet, as well as the SOVRONA Verifiable Data Registry (VDR).

25. SOVRONA D Wallet. SOVRONA D Wallet is a Digital Wallet (PDR (Private Data Registry)) that is controlled by SOVRONA, an Organization.

26. SOVRONA DD. SOVRONA DD is the primary DIDDOC (DID Document) for SOVRONA, an Organization.

27. DID:SVRN:ORG:01E9CFEA-E36D-4111-AB68-D99AE9D86D51#fdom1. DID:SVRN:ORG:01E9CFEA-E36D-4111-AB68-D99AE9D86D51#fdom1 is the identifier for the primary AGENT for SOVRONA, an Organization.

28. SOVRONA DD MVCA. SOVRONA DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for SOVRONA’s DID Document (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of itself for SOVRONA’s DD. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is SOVRONA, the Organization.)

11. VE-ARM “All-In” Graph View

The following is a depiction of the “All-In” view of the The Verifiable Economy Architecture Reference Model (VE-ARM) graph. This graph view represents the union of all of the previous subgraphs.

Figure 11. Subgraph F10. The Verifiable Economy “All-In” Graph View

11.1 Narrative

1. Erin. Erin is a RW_PERSON (“Real World” Person) and a citizen of the Province of Sovronia. Erin also holds a (valid) Sovronia Driver’s License (SDL) and controls a “Real World” Wallet (RW_WALLET) as well as a Digital Wallet (PDR).

2. Erin D Wallet. Erin D Wallet is a Digital Wallet (PDR (Private Data Registry)) controlled by Erin, a Person.

3. Erin DD. Erin DD is the primary DIDDOC (DID Document) for Erin, a Person. It is issued by SOVRONA who records it on the SOVRONA VDR and it is also held in the Erin DD Wallet.

4. DID:SVRN:PERSON:04900EEF-38E7-487E-8D6F-09D6C95D9D3E#fdom1. DID:SVRN:PERSON:04900EEF-38E7-487E-8D6F-09D6C95D9D3E#fdom1 is the identifier for the primary AGENT for Erin, a Person.

5. http://services.sovronia.ca/agent. http://services.sovronia.ca/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by the Province of Sovronia, an Organization. This includes all of the DID(s) and DID Document(s) associated with Erin.

6. SOVRONA VDR. SOVRONA VDR is the primary VDR (Verifiable Data Registry) controlled by SOVRONA, an Organization. The SOVRONA VDR is used to host the SVRN DID Method.

7. Erin DD MVCA. Erin DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s DID Document at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods to Erin.)

8. PoS RW Nation State. The Province of Sovronia is a (fictitious) Province (RW_NATIONSTATE (“Real World” Nation State)) in Canada and the legal government jurisdiction for the citizens of the province. The Province of Sovronia is an Organization. The Province of Sovronia issues “Real World” Sovronia Driver’s Licenses (SDLs) but relies on SOVRONA to issue digital, verifiable SDLs.

9. PoS D Wallet. PoS D Wallet is a Digital Wallet (PDR (Private Data Registry)) controlled by the Province of Sovronia, an Organization.

10. PoS DD. PoS DD is the primary DIDDOC (DID Document) for the Province of Sovronia, an Organization. It is issued by SOVRONA who records it on the SOVRONA VDR and it is held in the PoS D Wallet.

11. DID:SVRN:ORG:0E51593F-99F7-4722-9139-3E564B7B8D2B#fdom1. DID:SVRN:ORG:0E51593F-99F7-4722-9139-3E564B7B8D2B#fdom1 is the identifier for the primary AGENT for the Province of Sovronia, an Organization.

12. http://services.sovrona.com/agent. http://services.sovrona.com/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by SOVRONA, an Organization.

13. PoS DD MVCA. PoS DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for the Province of Sovronia’s DID Document (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of itself for the Province of Sovronia. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods to the Province of Sovronia.)

14. Erin SDL DD. Erin SDL DD is the primary DIDDOC (DID Document) for Erin’s digital, verifiable SDL.

15. Erin SDL MVCA. Erin SDL MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

16. Erin SDL Prop Set DD. Erin SDL Prop Set DD is the primary DIDDOC (DID Document) for the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop Set, a Verifiable Credential associated with the DID in Erin SDL Prop Set DD.

17. Erin SDL Prop Set MVCA. Erin SDL Prop Set MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL Prop Set (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

18. Erin SDL VCA. Erin SDL VCA is the Verifiable Capability Authorization (VCA) created for Erin’s SDL Prop Set DD. The VCA was issued by the Province of Sovronia authorizing Erin to be able to present the properties (and their values) of Erin’s SDL to a third party using the Present method associated with Erin’s SDL Prop Set and supported (implemented) by Erin’s AGENT. The parent of Erin’s SDL VCA is the Erin SDL MVCA.

19. Erin SDL VCA MI. Erin SDL VCA MI is an example of a MVCA Method Invocation (VCA MI) that uses the Erin SCL VCA which authorizes the potential execution of the Present method by Erin against Erin’s SDL Prop Set.

20. Erin SDL Prop Set VC. Erin SDL Prop Set VC is the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop Set VC, a Verifiable Credential associated with the DID in Erin SDL Prop Set DD.

21. DID:SVRN:VC:0B114A04-2559-4C68-AE43-B7004646BD76#fdom1. DID:SVRN:VC:0B114A04-2559-4C68-AE43-B7004646BD76#fdom1 is the identifier for the primary AGENT for Erin SDL Property Set DD.

22. Erin RW Wallet. Erin RW Wallet is a RW_WALLET (“Real World” (Leather) Wallet) and it is used to hold Erin’s “Real World” Sovronia Driver’s License (Erin RW SDL). Erin RW Wallet is owned and controlled by Erin.

23. Erin RW SDL. Erin RW SDL is Erin’s RW_SDL (“Real World” Sovronia Driver’s License) and it is held by Erin in Erin’s RW Wallet.

24. SOVRONA Organization. SOVRONA is an Organization and the primary “Real World” TDIDP (RW_DIDPROVIDER) for the citizens and government of Sovronia, a fictitious province in Canada. SOVRONA controls a Digital Wallet (PDR (Personal Data Registry)), SOVRONA D Wallet, as well as the SOVRONA Verifiable Data Registry (VDR).

25. SOVRONA D Wallet. SOVRONA D Wallet is a Digital Wallet (PDR (Private Data Registry)) that is controlled by SOVRONA, an Organization.

26. SOVRONA DD. SOVRONA DD is the primary DIDDOC (DID Document) for SOVRONA, an Organization.

27. DID:SVRN:ORG:01E9CFEA-E36D-4111-AB68-D99AE9D86D51#fdom1. DID:SVRN:ORG:01E9CFEA-E36D-4111-AB68-D99AE9D86D51#fdom1 is the identifier for the primary AGENT for SOVRONA, an Organization.

28. SOVRONA DD MVCA. SOVRONA DD MVCA is the Master Verifiable Capability Authorization (MVCA) created for SOVRONA’s DID Document (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of itself for SOVRONA’s DD. (A new MVCA is created whenever a new DID and DID Document are issued by a TDIDP. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is SOVRONA, the Organization.)

29. DID:SVRN:LICENSE:999902-638#fdom1. DID:SVRN:LICENSE:999902-638#fdom1 is the identifier for the primary AGENT for Erin SDL DD.

12. Conclusions

The goals of this article are three-fold:

  1. Introduce the concept of a Verifiable Capability Authorizations (VCA) and how they can be used to implement controls over which specific methods a particular party is allowed to execute against a particular instance of a Fully Decentralized Object (FDO). VCAs are both delegatable and attenuatable.
  2. Illustrate how #graphitization techniques can be used for visualizing:
    • Trusted Decentralized Identifiers (DIDs)
    • DID Documents
    • Trusted Digital Agents (and their Service Endpoints (SEPs))
    • Verifiable Credentials (VCs)
    • Verifiable Capability Authorizations (VCAs) and,
    • Most importantly, their myriad of interrelationships.
  3. Use the above 2 goals to further detail and describe how to use the VE-ARM model for implementing trusted, reliable, efficient, frictionless, standards-based, global-scale software systems based on Fully Decentralized Objects (FDOs).

This article described The Verifiable Economy Architecture Reference Model (VE-ARM) using a #graphiziation approach for modeling and visualization. The resulting overall graph was partitioned into a series of subgraphs that depict the key elements of the architecture reference model. Each subgraph was documented with a narrative that is mapped to the numbered blue targets used to identify each element in each subgraph .

1 Comment

Filed under Uncategorized

The Verifiable Economy: Architecture Reference Model (VE-ARM) 0.1: Original Concepts [OLD]

Michael Herman
Hyperonomy Digital Identity Lab
Trusted Digital Web Project
Parallelspace Corporation

NOTE: This article has been superseded by a newer article:

Introduction

This visualization represents the first complete iteration of The Verifiable Economy Architecture Reference Model (VE-ARM). It is the first complete example of a Fully-Decentralized Object Model (FDOM) that unites the following into a single integrated model:

  • Verifiable Identifiers, Decentralized Identifiers (DIDs), and DID Documents;
  • Verifiable Claims, Relationships, and Verifiable Credentials (VCs); and
  • Verifiable Capability Proclamations, Verifiable Capability Invocations, and Verifiable Capability Authorizations (VCAs).

Background

The scenario used to model the VE-ARM is an example of a citizen (Erin) of a fictional Canadian province called Sovronia holding a valid physical Sovronia Driver’s License (Erin RW SDL) as well as a digital, verifiable Sovronia Driver’s License (Erin SDL).

Figure 1. Erin’s Real-World Sovronia Driver’s License (Erin RW SDL)

Creation of the Verifiable Economy Architecture Reference Model (VE-ARM)

The underlying model was built automatically using a series of Neo4j Cypher queries running against a collection of actual DID Document, Verifiable Credential, and Verifiable Capability Authorization JSON files. The visualization was laid out using the Neo4j Browser. The resulting layout was manually optimized to produce the final version of the visualization that appears below. The numbered markers were added using Microsoft PowerPoint.

The Legends and Narration sections that follow further describe the VE-ARM in more detail. A whitepaper will be available shortly. The whitepaper will contain copies of the underlying DID Document, Verifiable Credential, and Verifiable Capability Authorization JSON files.

Click the image to enlarge it.

Figure 2. The Verifiable Economy Architecture Reference Model (VE-ARM)

Legend

Figure 3. Legend

Narrative

The numbered bullets in the following narrative refer to the corresponding numbered markers in Figure 2.

SOVRONA, a DID Provider (sovrona.com)

1. SOVRONA Organization. SOVRONA is an Organization and the primary Real-World DID Provider (RW_DIDPROVIDER) for the citizens and government of Sovronia, a fictitious province in Canada. SOVRONA controls a Digital Wallet (PDR (Personal Data Registry)), SOVRONA D Wallet, as well as the SOVRONA Verifiable Data Registry (VDR).

2. SOVRONA D Wallet. SOVRONA D Wallet is a Digital Wallet (PDR (Private Data Registry)) that is controlled by SOVRONA, an Organization.

3. SOVRONA DD. SOVRONA DD is the primary DIDDOC (DID Document) for SOVRONA, an Organization.

4. DID:SVRN:ORG:01E9CFEA-E36D-4111-AB68-D99AE9D86D51#fdom1. DID:SVRN:ORG:01E9CFEA-E36D-4111-AB68-D99AE9D86D51#fdom1 is the identifier for the primary AGENT for SOVRONA, an Organization.

5. http://services.sovrona.com/agent. http://services.sovrona.com/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by SOVRONA, an Organization.

6. SOVRONA VDR. SOVRONA VDR is the primary VDR (Verifiable Data Registry) controlled by SOVRONA, an Organization. The SOVRONA VDR is used to host the SVRN DID Method.

Province of Sovronia, an Organization and Nation State (sovronia.ca)

7. PoS Nation State. The Province of Sovronia is a (fictitious) Province (RW_NATIONSTATE (Real-World Nation State)) in Canada and the legal government jurisdiction for the citizens of the province. The Province of Sovronia is an Organization. The Province of Sovronia issues Real-World Sovronia Driver’s Licenses (SDLs) but relies on SOVRONA to issue digital, verifiable SDLs.

8. PoS D Wallet. PoS D Wallet is a Digital Wallet (PDR (Private Data Registry)) controlled by the Province of Sovronia, an Organization.

9. PoS DD. PoS DD is the primary DIDDOC (DID Document) for the Province of Sovronia, an Organization.

10. DID:SVRN:ORG:0E51593F-99F7-4722-9139-3E564B7B8D2B#fdom1. DID:SVRN:ORG:0E51593F-99F7-4722-9139-3E564B7B8D2B#fdom1 is the identifier for the primary AGENT for the Province of Sovronia, an Organization.

Erin Amanda Lee Anderson, a Person and Citizen of Sovronia (and Sovronia Driver’s License Holder)

11. Erin. Erin is a RW_PERSON (Real-World Person) and a citizen of the Province of Sovronia. Erin also holds a (valid) Sovronia Driver’s License (SDL) and controls a Real-World Wallet (RW_WALLET) as well as a Digital Wallet (PDR).

12. Erin D Wallet. Erin D Wallet is a Digital Wallet (PDR (Private Data Registry)) controlled by Erin, a Person.

13. Erin DD. Erin DD is the primary DIDDOC (DID Document) for Erin, a Person.

14. Erin RW Wallet. Erin RW Wallet is a RW_WALLET (Real-World (Leather) Wallet) and it is used to hold Erin’s Real-World Sovronia Driver’s License (Erin RW SDL). Erin RW Wallet is owned and controlled by Erin.

20. DID:SVRN:PERSON:04900EEF-38E7-487E-8D6F-09D6C95D9D3E#fdom1. DID:SVRN:PERSON:04900EEF-38E7-487E-8D6F-09D6C95D9D3E#fdom1 is the identifier for the primary AGENT for Erin, a Person.

Erin’s Sovronia Driver’s License

  • Verifiable Identifiers, Decentralized Identifiers (DIDs), and DID Documents;
  • Verifiable Claims, Relationships, and Verifiable Credentials (VCs); and
  • Verifiable Capability Proclamations, Verifiable Capability Invocations, and Verifiable Capability Authorizations (VCAs).

15. Erin RW SDL. Erin RW SDL is Erin’s RW_SDL (Real-World Sovronia Driver’s License) and it is held by Erin in Erin’s RW Wallet.

16. Erin SDL DD. Erin SDL DD is the primary DIDDOC (DID Document) for Erin’s digital, verifiable SDL.

17. Erin SDL Prop VC DD. Erin SDL Prop VC DD is the primary DIDDOC (DID Document) for the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop VC, a Verifiable Credential associated with the DID in Erin SDL Prop VC DD.

18. Erin SDL Prop VC. Erin SDL Prop VC is the Verified Credential (VC) that is used to represent the properties of Erin’s digital, verifiable SDL (and their values). The properties (and their values) are represented in Erin SDL Prop VC, a Verifiable Credential associated with the DID in Erin SDL Prop VC DD.

19. LicenseBackgroundImage. LicenseBackgroundImage is an IPFSIMAGE (IPFS Image Resource) used to store the Background License Image to be used in Erin’s digital and verifiable SDL. The URL of this resources is one of the property values represented in the Erin SDL Prop VC.

19. PhotoImage. PhotoImage is an IPFSIMAGE (IPFS Image Resource) used to store the Erin’s official photo. The URL of this resources is one of the property values represented in the Erin SDL Prop VC.

19. ProvinceStateLogoImage. ProvinceStateLogoImage is an IPFSIMAGE (IPFS Image Resource) used to store the office Provincial (or State) Logo Image to be used in Erin’s digital and verifiable SDL. The URL of this resources is one of the property values represented in the Erin SDL Prop VC.

19. SignatureImage. SignatureImage is an IPFSIMAGE (IPFS Image Resource) used to store the image of Erin’s official signature. The URL of this resources is one of the property values represented in the Erin SDL Prop VC.

21. DID:SVRN:LICENSE:999902-638#fdom1. DID:SVRN:LICENSE:999902-638#fdom1 is the identifier for the primary AGENT for Erin SDL DD, the DID Document for the “root” of Erin’s digital, verifiable Sovronia Driver’s License.

22. DID:SVRN:VC:0B114A04-2559-4C68-AE43-B7004646BD76#fdom1. DID:SVRN:VC:0B114A04-2559-4C68-AE43-B7004646BD76#fdom1 is the identifier for the primary AGENT for Erin SDL Prop VC DD, the DID Document for the Verified Credential used to represent the properties (and values) of Erin’s digital, verifiable Sovronia Driver’s License.

23. http://services.sovronia.ca/agent. http://services.sovronia.ca/agent is the primary SEP (Service Endpoint) for accessing the AGENT(s) associated with the DID(s) and DID Document(s) issued by the Province of Sovronia, an Organization. This includes all of the DID(s) and DID Document(s) associated with Erin and Erin’s SDL.

Erin’s Sovronia Driver’s License Verifiable Capability Authorizations (VCAs)

26. Erin SDL MVCA. Erin SDL MVCA is the Master Verifiable Capability Authorization (MVCA) created for Erin’s SDL (DD) at the time that the DID and DID Document were first issued by SOVRONA on behalf of the Province of Sovronia for Erin’s SDL. (A new MVCA is created whenever a new DID and DID Document are issued by a DID Provider. The MVCA grants authorization for any and all methods defined for the subject to the effective issuer. In this case, the effective issuer is the Province of Sovronia.)

25. Erin SDL VCA. Erin SDL VCA is the Verifiable Capability Authorization (VCA) created for Erin’s SDL Prop VC DD. The VCA was issued by the Province of Sovronia authorizing Erin to be able to present the properties (and their values) of Erin’s SDL to a third party using the Present method associated with Erin’s SDL Prop VC and supported (implemented) by Erin’s AGENT. The parent of Erin’s SDL VCA is the Erin SDL MVCA. (This is not illustrated correctly in the current version of Figure 2.)

24. Erin SDL VCA MI. Erin SDL VCA MI is an example of a MVCA Method Invocation (VCA MI) that uses the Erin SCL VCA which authorizes the potential execution of the Present method by Erin against Erin’s SDL Prop VC. (This is not illustrated correctly in the current version of Figure 2.)

NOTE: The domains sovrona.com and sovronia.ca are owned by the author.

1 Comment

Filed under Uncategorized

Trusted Digital Web Glossary (TDW Glossary): All-In View (latest version)

Click to enlarge.

TDW Glossary: All-In View (latest version)

Leave a comment

Filed under Uncategorized

Why is a Glossary like a Network of Balls connected by Elastics?

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.

The TDW Glossary is a huge, visual, highly interrelated, multi-disciplinary, multi-standard, 6-domain, semantic network model (https://hyperonomy.com/2021/03/10/tdw-glossary-management-platform-gmp-initial-results/) that includes:

  1. Common English Language concepts – various dictionaries and reference web sites
  2. Sovrin Glossary concepts – https://sovrin.org/library/glossary/ and https://mwherman2000.github.io/sovrin-arm/
  3. Enterprise Architecture concepts – https://pubs.opengroup.org/architecture/archimate3-doc/
  4. HyperLedger Indy Architecture Reference Model concepts – https://mwherman2000.github.io/indy-arm/
  5. HyperLedger Aries Architecture Reference Model concepts – https://mwherman2000.github.io/indy-arm/
  6. Did-core concepts – https://w3c.github.io/did-core/
  7. VC concepts – https://w3c.github.io/vc-data-model/
  8. Others?

All new and updated terms, their definitions, metadata, and relationships, are automatically being published here: https://github.com/mwherman2000/tdw-glossary-1 (e.g. https://github.com/mwherman2000/tdw-glossary-1/blob/e4b96a0a21dd352f67b6bd93fdac66a1599ed35f/model/motivation/Principle_id-72c83ae5b01346b7892e6d2a076e787f.xml)

Other references:

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.

Cheers,
Michael

Figure 1. TDW Glossary: “All In” View

Leave a comment

Filed under Uncategorized

TDW Glossary: Self-Sovereign Identity (SSI) User Scenarios: Erin Buys a Car in Sovronia (3 User Scenarios)

To download this user scenario white paper, click here:

Figure 1. Trusted Digital Web Glossary (TDW Glossary): Self-Sovereign Identity (SSI) User Scenarios: Erin Buys a Car in Sovronia (3 User Scenarios)

1 Comment

Filed under Uncategorized

Healthcare Claim Processing User Scenario

Figure 1. Healthcare Claim Data Flow

Related References

  1. Here in Alberta, a province-wide digital ID (MyAlberta Digital ID) is being rolled to to each citizen (https://account.alberta.ca/available-services).
  2. The MyAlberta Digital ID will used to access and manage all Alberta Health Services (https://myhealth.alberta.ca/myhealthrecords) including vaccination records.
  3. MyAHS Connect Frequently Asked Questions (https://myahsconnect.albertahealthservices.ca/MyChartPRD/Authentication/Login?mode=stdfile&option=faq)

Leave a comment

Filed under Uncategorized

DIF SDS/CS WG: CS Refactoring Proposal 0.2 – March 24, 2021

Contents

  1. Latest Version of the Proposal (0.2 – March 24, 2021)
  2. Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
  3. Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call
  4. 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.

Figure 1. CS Specification Refactoring Proposal 0.2

Dependencies

  1. 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.
  2. 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.
  3. 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

_._,_._,_


Links:

You receive all messages sent to this group.

View/Reply Online (#122) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [mwherman@parallelspace.net]

_._,_._,_

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

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Sent: March 24, 2021 7:38 AM
To: sds-wg@lists.identity.foundation; sds-wg@dif.groups.io; Credentials Community Group <public-credentials@w3.org>; Daniel Buchner <daniel.buchner@microsoft.com>
Subject: 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

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

I’ve posted this partial transcription here: https://hyperonomy.com/2021/03/24/transcription-of-selected-parts-of-the-dif-sds-cs-march-11-2021-zoom-call-hub-and-edv-discussion-featuring-daniel-buchners-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?”.

Have a great day, afternoon, or evening,

Michael

4. OSI Stack Proposal for Confidential Storage Specification

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Sent: March 24, 2021 7:10 AM
To: sds-wg@lists.identity.foundation; sds-wg@dif.groups.io; Credentials Community Group <public-credentials@w3.org>; Daniel Buchner <daniel.buchner@microsoft.com>
Subject: RE: Is there an equivalent to the “OSI Network Stack” but for storage and storage access?

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

Leave a comment

Filed under Uncategorized

Microsoft SharePoint Products and Technologies: 20th Anniversary Celebration

Microsoft “Tahoe” Airlift and RC1 Announcements

Figure 1. Microsoft SharePoint Evolution
Figure 2. Microsoft SharePoint Portal Server 2001: Installation Splash Screen

Microsoft Products and Technologies Whitepapers

Client: Microsoft Corporation SharePoint Product Group / Microsoft IT Showcase

Exchange 2000 Web Storage System Articles

Outlook 10 Drops Support for the Local Web Storage System Articles

Leave a comment

Filed under Uncategorized