Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor

COPYRIGHT © 2016-2017 by Michael Herman, Seattle, Washington and Toronto, Canada. All rights reserved.

Michael Herman is an expert when it comes to the mathematical modeling, analysis, and visualization of almost everything:

  • Large enterprise organizations,
  • Commercial, global-scale, cloud services platforms,
  • Organization principles and belief systems,
  • Human platforms,
  • Aircraft engines, and
  • Muscle cars.

Michael is the inventor of the #Graphitization Continous Transformation Model – a closed-closed loop feedback process for the ingestion, modeling, analysis, visualization, systems optimization, and life cycle management of any type of strategy, system, asset, architecture, or process.

progressive-ea-model-1-0-11-peam4-operational-data-chasm

Figure 1. #Graphitization Continuous Transformation Model

A key concept of #Graphitization is the implementation of Transformative Changes that result in positive increases in business value in the system being modeled.

#Graphitization

What is #Graphitization?

#Graphitization is a data science and enterprise architecture framework and process model for modeling, ingesting, organizing, analyzing, and visualizing any domain of endeavor by using graphs – networks of connected objects and relationships with each object and relationship annotated with additional descriptive information (metadata).

The primary applications of #Graphitization are:

  • System optimization,
  • Systems life cycle management, and
  • Transformative Change in resulting in positive increases in business value for the system being studied.

A system is defined as any collection of strategies, system components, assets, architectures or processes.

References

#Graphitization Continuous Transformation Model

The #Graphitization general model is described in Figure 2. as it applies to the design and optimization of large enterprise organizations.

progressive-ea-model-1-0-11-peam4-operational-data-chasm

Figure 2. #Graphization Continuous Transformation Model: Large Enterprise Organizations

The same model can also be used to improve the design and operation of many different types of systems:

  1. Large scale enterprise organizations (public and private sector)
  2. Aircraft engines, muscle cars, and other high-performance engine systems
  3. Commercial, global-scale, cloud services platforms
  4. Automated service composition of cloud services-based data systems
  5. Large collaborative ecosystems: employee groups, business partners, social networks
  6. Large ecosystems of competing or competitive business organizations
  7. Organization principles and belief systems
  8. Conventions software applications and architectures: desktop, server, and web apps
  9. International standards for visual modeling languages
  10. Parallelspace ModelMate
  11. Enterprise Data Management
  12. Internet of Things (IoT)
  13. Architecture Reference Models

Standards

NEO Enhancement Proposal (NEP) Standards Author

Projects and Publications

0. SerentityData Graph

Model-based off-chain and on-chain (blockchain) graph data creation, migration, visualization, and analysis

Abstract

SerentityData Graph is an entity-relationship modeling, serialization, and graph analysis solution that supports development of traditional full-stack and blockchain smart contract applications. SerentityData features tight Neo4j integration for on-chain & off-chain graph data visualization and analysis.

Description

SerentityData Graph is an open source, entity-relationship modeling, serialization, and graph data visualization and analysis solution that supports the development of traditional full-stack, blockchain-based smart contract, and Neo4j graph database applications.

Starting from a single data model, SerentityData supports the automatic code generation of entities and relationships that support symmetric development of: (a) off-chain data in traditional multi-tier full-stack applications, (b) on-chain data management for blockchain-based distributed ledger technology apps (dApps), and (c) Neo4j enterprise graph applications.

SerentityData features complete life-cycle integration with Neo4j for on-chain and off-chain graph data creation, migration, visualization, and analysis. Live code walk-throughs and demonstrations will enable you to begin using SerenityData and Neo4j immediately. Github: https://github.com/mwherman2000/serentitydata-compiler

Resources

My blog: https://hyperonomy.com/

Related blog posts

  1. Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor https://hyperonomy.com/2017/05/18/michael-herman-inventor-of-graphitization/
  2. #Graphitization of the Enterprise https://hyperonomy.com/2017/01/02/graphitization-of-the-enterprise/
  3. Tokenize Every Little Thing (ELT) https://hyperonomy.com/2018/01/24/tokenization-of-every-little-thing-elt/
  4. #Graphitization of .NET Applications: Marrying Open EA Data with Graph Databases https://hyperonomy.com/2016/10/19/crossing-the-ea-chasm-marrying-open-ea-data-with-graph-databases/
  5. #Graphitization of Ray Dalio’s Principles: Iteration 1 https://hyperonomy.com/2016/12/29/graphitization-of-ray-dalios-principles/
  6. #Graphitization of Ray Dalio’s Principles: Iteration 2 https://hyperonomy.com/2016/12/30/graphitization-of-ray-dalios-principles-iteration-2/
  7. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1 https://hyperonomy.com/2017/01/17/crossing-the-ea-chasm-graphitization-of-archimate-3-0/
  8. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 2 https://hyperonomy.com/2017/02/08/crossing-the-ea-chasm-graphitization-of-archimate-3-0-iteration-2/
  9. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1 https://hyperonomy.com/2016/10/22/crossing-the-ea-chasm-automating-enterprise-architecture-modeling/
  10. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2 https://hyperonomy.com/2016/11/04/crossing-the-ea-chasm-automating-enterprise-architecture-modeling-2/
  11. Crossing the EA Chasm: ArchiMate “Keep Calm and Have IT Your Way” https://hyperonomy.com/2016/11/17/crossing-the-ea-chasm-archimate-have-it-your-way/
  12. Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture https://hyperonomy.com/2016/10/04/the-ea-chasm-open-repository-strategies-for-enterprise-architecture/
  13. Crossing the EA Chasm: Enterprise Architecture Diagrams Your Grandmother (and CIO) Will Love https://hyperonomy.com/2016/10/13/archimate-diagrams-your-grandmother-and-cio-will-love/
  14. #Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository https://hyperonomy.com/2017/02/10/crossing-the-ea-chasm-how-to-use-the-modelmate-online-repository-mmor/
  15. #Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1 https://hyperonomy.com/2017/05/08/amazons-principles/
  16. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale? https://hyperonomy.com/2017/04/10/whats-the-difference-between-improving-the-design-and-operation-of-an-aircraft-engine-a-muscle-car-a-large-enterprise-and-a-commercial-global-cloud-services-platform/

Live Neo4j Models

  1. http://hobby-icgaeohcoeaggbkeabhldpol.dbs.graphenedb.com:24789/browser/ Userid: ModelMate_Master_Datasets10 Password: YqeZAH4ODEJqglkEsK5p

YouTube Channel: https://www.youtube.com/playlist?list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5

  1. 12. NEO Persistable Classes (NPC) Platform 2.1: Preview https://www.youtube.com/watch?v=N-jiJOZwiFg&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=5
  2. NEO Persistable Classes (NPC) Platform 2.0: Deep Dive https://www.youtube.com/watch?v=Nj4-m2o94VE&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=6
  3. NEO Persistable Classes 1.0: Deep Dive (Video 2 of 3) [Update 1] https://www.youtube.com/watch?v=qwteL1BiCjM&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=7
  4. NEO Persistable Classes Platform 2.2: Structured Storage & Reusable, Indexed, Non-Fungible Entities https://www.youtube.com/watch?v=vnAxyCAZ1ec&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=10

Related Github Projects

  1. SerentityData Entity Compiler (serentitydata-compiler) https://github.com/mwherman2000/serentitydata-compiler/blob/master/README.md
  2. NEO Persistable Classes (NPC) Compiler 2.1 (npcc) – Compiler for the NEO Persistable Classes (NPC) Platform 2.1 https://github.com/mwherman2000/neo-npcc2
  3. NEO Persistable Classes V1.0 – An Efficient Object-Oriented Framework for C#.NEO Smart Contract Development (ORIGINAL) – https://github.com/mwherman2000/neo-persistibleclasses

Recognition

  1. NeoDraw – NEO Persistable Classes Platform 2.0: NEO-Microsoft dApp Competition (4th place prize – USD$15,000) – https://neo.org/blog/details/3074 and https://neo.org/awards.html

Keywords

  • blockchain on-chain data modeling symmetric programming data management .NET C# NEO Stratis Ethereum Technical Case Study Developer Best Practices

1. Large scale enterprise organizations (public and private sector)

The first applications of #Graphitization were in the field of traditional enterprise architecture modeling and analysis:

  • Business Architecture
  • Application Architecture
  • Technology/Infrastructure Architecture

References

  1. #Graphitization of the Enterprise
  2. Crossing the Chasm: Progressive Enterprise Architecture Model (PEAM)
  3. Progressive Enterprise Architecture Maps – Update 2
  4. Using ArchiMate 2.1 to Model Product or Service Markets
  5. ArchiMate 3.0: What is the preferred way to model a Server Farm?
  6. Crossing the EA Chasm: Enterprise Architecture Diagrams Your Grandmother (and CIO) Will Love
  7. Crossing the EA Chasm: Annotating Your EA Models with RACI Roles
  8. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1
  9. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2
  10. Crossing the Enterprise Architecture Chasm
  11. ModelMate Architecture Reference Model
  12. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?
  13. Modeling a Company and Its Locations, Markets, Employees, Investors & Roles: Proposals, Wishes & Dreams

2. Aircraft engines, muscle cars, and other high-performance engine systems

It turns out that the modeling and analysis of any complex system is an ideal candidate for #Graphitization.

References

  1. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

3. Commercial, global-scale, cloud services platforms

One particularly important application is the modeling and analysis of very large, commercial, global-scale, cloud services platforms.

References

  1. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

4. Automated service composition of cloud services-based data systems

Call the solution “Expedia for Microsoft Azure/AWS/SFDC/…” or whatever you prefer, today’s commercial cloud services platforms are still a pain in the ass to use for creating non-trivial applications.  Left, right, and center you have to hand-code a myriad of worker processes simply to reformat and pass data around.

#Graphitization is an optimal approach for modeling the underlying cloud services platform services catalog.

References

  1. MS Azure is a bit of a bucket of bolts …very good bolts …but relative to the other IoT vendors, a bucket of bolts.
  2. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?
  3. Microsoft Azure Stack POC Architecture Reference Model (ARM): ArchiMate Model – version 1-0-7 – April 30, 2016

5. Large collaborative ecosystems: employee groups, business partners, social networks

Project “Boston” is named after some potential business partners and the embryo for the idea coming from my months as a founding Groove Networks business partner (including many of my most important relationships that I still maintain today).

6. Large ecosystems of competing or competitive business organizations

Modeling of large ecosystems of competing/competitive business organizations is a straightforward #Graphitization use case.

7. Organization principles and belief systems

On the surface, the #Graphitization of principle and belief-based frameworks is pretty straightforward but this is because the basic #Graphitization serves as the substrate for many advanced data ingestion, analysis, and visualization projects.

Below are the results of the  #Graphitization of two principle and belief-based frameworks:

  • Bridgewater Associates: Ray Dalio’s Principles
  • Amazon: Jeff Bezos’ Amazon Leadership Principles

References

  1. #Graphitization of Ray Dalio’s Principles: Iteration 1
  2. #Graphitization of Ray Dalio’s Principles: Iteration 2
  3. #Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1

8. Conventional software applications and architectures: desktop, server, and web apps

Modeling of complex, multi-language, multiple runtime software environments is a use case that is an ideal application of #Graphitization.

References

  1. #Graphitization of .NET Applications: Marrying Open EA Data with Graph Databases
  2. Pinc-A Tool For Maintaining Configurable Software in Pascal1
  3. Pinc-A Tool For Maintaining Configurable Software in Pascal2
  4. Pinc-A Tool For Maintaining Configurable Software in Pascal3
  5. Pinc-A Tool For Maintaining Configurable Software in Pascal4
  6. Pinc-A Tool For Maintaining Configurable Software in Pascal5

9. International standards for visual modeling languages

A significant investment has been made in applying #Graphitization to language modeling; specifically, languages for enterprise architecture like ArchiMate.

ArchiMate References

  1. Using ArchiMate 2.1 to Model Product or Service Markets
  2. ArchiMate 3.0: What is the preferred way to model a Server Farm?
  3. How do I model “X” using ArchiMate?
  4. Crossing the EA Chasm: ArchiMate “Keep Calm and Have IT Your Way”
  5. Crossing the EA Chasm: ArchiMate Art
  6. Crossing the EA Chasm: Re-visioning the ArchiMate Specification
  7. Crossing the EA Chasm: Reflections on the Current State of ArchiMate
  8. Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Relations as Verbs
  9. Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Elements as Adjectives [WIP]
  10. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1
  11. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 2 (long but meaty)
  12. #Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository

10. Enterprise Data Management

Modeling and analyzing enterprise data structures and stores is a common application of #Graphitization; including the modeling of taxonomies and master data.

References

  1. RE: Managing Master Data With ArchiMate

11. Parallelspace ModelMate

Parallelspace ModelMate is an approach (platform and language framework) for creating domain specific languages (DSLs) for enterprise architecture.  It is realized using #Graphitization and the ArchiMate enterprise architecture modeling language.

References

  1. Crossing the Enterprise Architecture Chasm
  2. Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture
  3. ModelMate Architecture Reference Model

12. Internet of Things (IoT)

IoT is an interesting beast.  It is a reference to an application service for processing raw events from a device or dynamically generated events from a software system.  IoT also defines a conceptual software and data flow architecture that can also be used for the dynamic creating and maintenance of complex systems such as large enterprise architectures.

References

  1. Subject: MS Azure Services: Is there an overarching architectural vision?
  2. MS Azure is a bit of a bucket of bolts …very good bolts …but relative to the other IoT vendors, a bucket of bolts.
  3. Crossing the EA Chasm: “Where does IoT [Internet of Things] fit in?”

13. Architecture Reference Models (ARMs)

An ARM is easily modeled (and analyzed) using #Graphitization.  SharePoint and Azure Stack are two good examples.

References

  1. ARMs for Model-Driven LOB apps: SharePoint 2013/SharePoint 2016 [Oct. 24, 2016]
  2. Microsoft Azure Stack POC Architecture Reference Model (ARM): ArchiMate Model – version 1-0-7 – April 30, 2016

General References

  1. Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
  2. To dig deeper, check out Graphitization of the Enterprise (click here)
  3. [Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)
  4. Crossing the EA Chasm: The Surveyor

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

  • ArchiMate is registered trademark of The Open Group.

1 Comment

Filed under ArchiMate, Architecture Reference Models, Automated Application Architecture Analysis, Automated Enterprise Architecture Modeling, Graphitization, How do we think, Microsoft Azure, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages

What are the differences between improving the design (and operation) of a smart city, an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved. [Updated June 16, 2018]

Question: What are the differences between improving the design (and operation) of:

  • a smart city,
  • an aircraft engine,
  • a muscle car,
  • a large enterprise, and/or
  • an integrated commercial global cloud services platform
  • …all running at hyperscale?

Answer: None.

Scroll down to see the use cases; then the list of resources at the bottom of this article.

Use Case 1: Aircraft engine, and
Use Case 2: 
Muscle car

Continuous Transformation 2

Figure 1. Continuous Transformation Model: Aircraft Engines and Muscle Cars

Use Case 3: Smart city,
Use Case 4: Large enterprise operating at hyperscale, and
Use Case 5: 
Integrated commercial global cloud services platform operating at hyperscale

Continuous Transformation 1.png

Figure 2. Continuous Transformation Model: Smart Cities, Large Enterprises, and Cloud Services Platforms

Diving Deeper: #Graphitization

To go deeper, checkout #Graphitization of the Enterprise (click here) as well as the list of references below.

progressive-ea-model-1-0-9-peam3-ea-chasm-auto-dots

Figure 3. #Graphitization Continuous Transformation Model

 

progressive-ea-model-1-0-11-peam5-1010

Figure 4. Continuous Transformation Framework: Process Groups and Activities

References

  1. Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor  (click here)
  2. Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
  3. To dig deeper, check out Graphitization of the Enterprise (click here)
  4. [Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

1 Comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Data Science, Enterprise Architecture, Graphitization, How do we think, IoT, Space Flight

Michael Herman: Award-winning Author, Invited Speaker, Illustrator, and Trainer

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

Feel free to contact me at:

PARTIAL PORTFOLIO

All of the publications below are full-length white papers or technical notes – unless noted otherwise (e.g. presentations, training materials, online product help).

Microsoft Live Communications Server

Client: Microsoft Corporation Live Communications Server Product Group / Microsoft IT Showcase

Microsoft SharePoint Products and Technologies

Client: Microsoft Corporation SharePoint Product Group / Microsoft IT Showcase

Microsoft Exchange Server

Client: Microsoft Corporation Exchange Server Product Group / Microsoft IT Showcase

Metalogix Replicator for SharePoint

Client: Metalogix, market leading provider of solutions to move, manage and protect content within enterprise collaboration platforms in the cloud and on-premises.

Microsoft “Alchemy”

Client: Microsoft Web Services Product Group / Microsoft IT Showcase

Parallelspace Vulture

Client: Parallelspace Corporation

Tzunami K-Wise Deployer

Client: Tzunami

Leave a comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, Graphitization, How do we think, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages

#Graphitization of the Enterprise

COPYRIGHT © 2016-2017 by Michael Herman, Toronto Canada. All rights reserved. [Updated June 16, 2018]

This article is the first in a series on #Graphitization. Click here to explore the other articles in this series.

Reprinted from #Graphitization of the Enterprise on LinkedIn.

Move beyond digitalization of the enterprise to graphitization of the enterprise. Here’s a great diagram that explains this concept. (click on the diagram to enlarge it)

graphitization-new-world-of-it
Figure 1. The New Model of IT

Graphitization of not only all of your corporate information assets across all of your constituencies and stakeholders – at the data, application entity, and business object level – but also the graphitization of all of the interconnections between every business process, application system, infrastructure component, cloud service, vendor/service provider, and business role that uses, manages, or stores corporate information (Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2).

Use graphitization to make your existing corporate information more available, more usable, and more informative. Graphitization enables you to “Keep Calm and Have IT Your Way“.

What is #Graphitization?

#Graphitization is a data science and enterprise architecture-inspired framework and process model for modeling, ingesting, organizing, analyzing, and visualizing any domain of endeavor by using graphs – networks of connected objects and relationships with each object and relationship annotated with additional descriptive information (metadata).

The primary applications of #Graphitization are:

  • System optimization,
  • Systems life cycle management, and
  • Transformative Change in resulting in positive increases in business value for the system being studied.

A system is defined as any collection of strategies, system components, assets, architectures or processes.

Using #Graphitization

Use graphitization of your organization to help close both the Enterprise Architecture Chasm and the Operational Data Chasm. See below.

progressive-ea-model-1-0-11-peam4-operational-data-chasm
Figure 2. Continuous Transformation Framework: Enterprise Architecture Chasm and Operational Data Chasm

progressive-ea-model-1-0-11-peam5-1010
Figure 3. Continuous Transformation Framework: Process Groups and Activities

To learn more about other applications of graphitization, check out the following articles:

Best regards and best wishes for the New Year,

Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

6 Comments

Filed under continuous transformation, Crossing the EA Charm, Data Science, Digital Transformation, Enterprise Architecture, Enterprise Architecture Chasm, Graphitization, ModelMate, Operational Data Chasm, Progressive Enterprise Architecture Map (PEAM)

Hydroponic Pods

Leave a comment

June 2, 2021 · 11:26 pm

NETAGO Downtime – May 20-21, 2021

  • Hardwired ThinkPad laptop
    • Edition: Windows 10 Pro
    • Version: 20H2
    • OS build: 19042.928
    • 716 failures
    • 75.67% downtime

  • WiFi Wireless Lenovo laptop
    • Edition: Windows 10 Pro
    • Version: 20H2
    • OS build: 19042.985
    • 753 failures
    • 6.86% downtime

Leave a comment

Filed under Uncategorized

NETAGO Downtime – 2021-05-15 & 16

  • Hardwired ThinkPad laptop: 81.01% downtime (same laptop used for prior NUM reports)
  • WiFi Wireless Lenovo laptop: 3.78% downtime

Leave a comment

Filed under Uncategorized

NETAGO Downtime – 2021-05-14 AM

  • Hardwired ThinkPad laptop: 77.96% downtime (same laptop used for prior NUM reports)
  • WiFi Wireless Lenovo laptop: 2.99% downtime

Leave a comment

Filed under Uncategorized

NETAGO Downtime – 2021-05-13 AM – 88.81%

Over the last approximately 7.5 hours, the NETAGO internet service in Bindloss, Alberta was down 88.81% of the time according to the Net Uptime Monitor (NUM) app. This is not acceptable.

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

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

2021-05-12 10:19:45 PM Log Start

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

2021-05-13 5:48:22 AM 0:08:06

2021-05-13 5:56:36 AM Log End


Monitor Duration 7:36:50
Failure Summary:
Count 67
Total Downtime 6:45:44
% Downtime 88.81
Minimum Length 0:00:05
Maximum Length 0:21:49
Average Length 0:06:03

Leave a comment

Filed under Uncategorized

NETAGO Downtime – 2021-05-12 Early Morning – 93.6%

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

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

2021-05-12 3:24:40 AM Log Start

Failure Start Length
2021-05-12 3:26:48 AM 0:00:05
2021-05-12 3:27:08 AM 0:00:16
2021-05-12 3:28:06 AM 0:06:22
2021-05-12 3:34:36 AM 0:01:04
2021-05-12 3:35:48 AM 0:05:23
2021-05-12 3:43:30 AM 0:27:34
2021-05-12 4:11:13 AM 0:00:29
2021-05-12 4:11:56 AM 0:02:18
2021-05-12 4:14:55 AM 0:02:05
2021-05-12 4:17:09 AM 0:05:56
2021-05-12 4:23:13 AM 0:56:42
2021-05-12 5:20:23 AM 0:00:23
2021-05-12 5:21:46 AM 0:00:33
2021-05-12 5:22:27 AM 0:07:16
2021-05-12 5:29:51 AM 0:04:38
2021-05-12 5:34:38 AM 0:17:12
2021-05-12 5:51:58 AM 0:07:41
2021-05-12 5:59:54 AM 0:00:15
2021-05-12 6:02:15 AM 0:00:27
2021-05-12 6:02:50 AM 0:04:07
2021-05-12 6:07:37 AM 0:21:43

2021-05-12 6:29:28 AM 0:07:42

2021-05-12 6:37:22 AM Log End


Monitor Duration 3:12:41
Failure Summary:
Count 22
Total Downtime 3:00:21
% Downtime 93.60
Minimum Length 0:00:05
Maximum Length 0:56:42

Average Length 0:08:11

Leave a comment

Filed under Uncategorized

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