Giving Grammars Written with ABNF Notation the Respect They Deserve

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

At one level, the Augmented BNF (ABNF) notation is simply a convenient textual approach for describing a grammar. In turn, a grammar is a description of the allowable linguistic constructs permitted in a particular language or any other syntactic construction. Examples of common and emerging grammars written using ABNF notation include:

More importantly, a grammar that conforms to the ABNF specification (RFC4234-4) is also an executable program.  That is, a grammar is the source code for program (written in the ABNF notation (aka ABNF programming language)) that recognizes and, optionally, processes a piece of text (string of tokens) that conforms to the grammar’s specification (expressed using ABNF notation).

Summary: The “ABNF Principles”

The “ABNF Principles” include:

  1. “ABNF” is a specification for a notation for describing a grammar.
  2. “ABNF notation” is the notation described in the ABNF specification for describing a grammar.
  3. A grammar is a description of the allowable linguistic constructs permitted in a particular language or any other syntactic construction.
  4. RFC4234-4 is a formal specification for ABNF notation.
  5. A grammar expressed using ABNF notation is intended to be executable.
  6. A grammar expressed using ABNF notation is the source code for a program that can be read, interpreted, compiled, and/or executed by a human, interpreter, compiler, or virtual machine, respectively, in a way that conforms to the ABNF formal specification.

Best Practices for Developing Grammars Written using ABNF Notation

  1. As in any software development project, it is of primary importance to understand the scope of the functionality, inputs, and outputs of the intended software (aka requirements).
  2. One of the best, commonly accepted ways to understand of the scope of the intended software to be developed is to work through the following series of artifacts:
    1. User stories, which in turn are decomposed into
    2. Use cases, and
    3. Requirements, and
    4. Specifications
  3. Use automation together with the use cases to create an automatable testing framework starting early in the project – automatically validating the the grammar against the test cases (derived from the use cases) on an ongoing basis.

NOTE: These artifacts can be developed iteratively using an agile or other type of development framework. It doesn’t require a waterfall approach.

 

 

Leave a comment

Filed under Uncategorized

SerentityData: Variable-byte, Statistically-based Entity Serialization & Field Encoding

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

The SerentityData Entity Serialization and Field Encoding library fulfills Blockchain Requirement 1 for the Universal UBL (UUBL) extensions to the UBL 2.2 business document schema specification:

Requirement 1. Compact and Efficient Binary Serialization

The requirement for extremely compact and efficient binary serialization of each entity (and subentity) can be fulfilled by various software serialization solutions including SerentityData Variable-byte, Statistically-based Entity Serialization. The SerentityData project can be found on Github. SerentityData is the author’s preferred solution.

Design and Implementation Strategy

Design Principles

  1. Statistically-based Encodings (STE): For a particular datatype (e.g. Signed Int 16 or Unsigned Int 64), some data values representable by this datatype will be used more frequently than others (e.g. 0 (zero), 1, small integer values, etc.) and there should be a way to encode these statistically more frequent values using as few bytes as possible (compared to larger data values).
  2. Variable-byte Encodings (VBE): Over the lifespan of a persisted field (e.g. an Unsigned Int 64 blockchain block or transaction serial number), the initial values of the field will have small values (0, 1, 2, 3, …) and over the course of a long time (years or decades) grow to have very large values. As few bytes as possible should be used to represent small values and this should be less than the number of bytes required to represent very large values.
  3. Application-adaptive Encodings (AAE): Every application or application data domain will require:
    1. A different subset of the available datatypes, and
    2. Each data type will have a different statistical distribution of application-dependent data values.
  4. Single-byte Encodings (SBE): Very common (application-dependent) data values, on a datatype-by-datatype basis, should only require 1 (one) byte of storage. For example, for specific applications, the following values would be candidates for single-byte encodings:
    1. Data value TRUE of datatype Boolean and data value False of datatype Boolean
    2. Specific data values of small whole numbers (e.g. 0, 1, 2, 3, 4, 5, … n) where, depending on the application and datatype, n might be 10, 32 (days of the month), 60 (seconds in a minute), etc. The values do not have to be contiguous.
    3. Specific data values of negative numbers (e.g. -1, -2, -3, -4, -5, … m) where, depending on the application and datatype, m might be -10, -20, etc. The values do not have to be contiguous.
    4. Specific data values of Enum datatypes. The values are usually contiguous but there is no requirement for them to be contiguous.
  5. Support All Datatypes (SAD): It should be possible to encode all possible datatypes and all possible data values for the selected data types.  The current list of supported data types includes:
    1. Signed Integer 16
    2. Signed Integer 32
    3. Signed Integer 64
    4. Unsigned Integer 16
    5. Unsigned Integer 32
    6. Unsigned Integer 64
    7. Byte
    8. Signed Byte
    9. Enum
    10. Byte Array
    11. Boolean
    12. Boolean
    13. Char
    14. String
    15. ASCIIString
    16. Address
    17. Guid
  6. Standalone, Compact, and Efficient (SCE) Implementation
    1. Standalone: The entity serialization and field encoding libraries will not rely on any external source code or callable binary libraries.
    2. Compact: The entity serialization and field encoding libraries will be compact enough to be useful and desirable to execute:
      1. Off-chain in a traditional computing environment including server, PC, tablet, and mobile device, as well as
      2. On-chain in a smart contract (virtual machine) execution environment
    3. Efficient: Highly efficient code execution to be useful and desirable to use in a fee-based, smart contract (virtual machine) execution environment
  7. Storage Compatibility (SC): Compatible with any data storage technology capable of storing variable-length arrays of bytes representing the field encoded and entity serialized data.
  8. Runtime Compatibility (RC): The current design and implementation of the entity serialization and field encoding libraries is compatible with .NET Core 2.0 or later.
  9. Versioning Support (VS): Support for versioning at the entity serialization as well as entity encoding levels; including support for multiple applications, serializations and encodings in the same library.
  10. Entity Extensibility and Backward Compatibility (EEBC): Entity declarations can be extended through the additional fields without losing backward compatibility with previously serialized entities.
  11. Support for ByteArray and String Null-Valued References (NULLS): Support for null-valued references to ByteArrays and Strings – in addition to zero-length and non-zero length ByteArrays and Strings.

Assumptions

  1. There exists a code generation tool that takes as input a description of an entity, its fields and their datatypes that will create the sequence of calls into the entity serialization and field encoding that performs serialization/deserialization and field coding/decoding for a target entity declaration (e.g. a C# class declaration).

Implementation Notes

  1. The reference implementation of the entity serialization and field encoding libraries is called SerentityData and is implemented using .NET Core 2.0, C#, and Visual Studio 2007 Community Edition.

Roadmap

Features that are unsupported in the current release:

  1. Collections and Mappings: next on the queue
  2. Nested Entity Declarations: An entity declaration that has a field whose datatype is another entity declaration.

Field Encoding Strategy

TODO

Byte 0 Mapping

In the Variable Byte Encoding scheme used to represent the value of a datatype, the first byte of an encoded field value (Byte 0) is the most important. For Single-byte Encodings, Byte 0 needs to encode both the datatype of a particular value but also the value itself.

Given there are only 256 unique values that Byte 0 (or any single byte) can assume, certain trade-offs must be made to accommodate the range of application-driven datatypes required and the number of possible single-byte, double-byte, and triple-byte optimizations that are possible. This is where statistical knowledge of the range of values that a particular datatype required by an application is important.

Byte 0 Default Mapping

Figure 1 below is an example of the current default set of Byte 0 mappings.

SerentityData1.pngFigure 1. Byte 0 Default Mapping Table

Data value 0 (zero) is currently not assigned.

Single-Byte Encodings

TODO

Two-Byte Encodings

TODO

Three-Byte Encodings

TODO

Longer Byte Encodings

TODO

Performance

TODO

Sample Use Case

An example of a distributed business application designed to be used with SerentityData is the following SerentityDapp.Perfmon for on-chain [blockchain] performance monitoring and recording.

NCP-001 SerentityDapp.Perfmon v0.7Figure 2. SerentityDapp.Perfmon Data Model – Onchain [blockchain] Performance Monitoring and Recording Example

Appendix A – SerentityData Field Encoding Details

Supported Data Types

02-datatypes

Special Use Cases

21-specialcases

Field Buffer Configurations

A. Buffered Values

  • 3 Fields = FieldEncodingType + Buffer Length + Buffer Bytes
Use Case 0. 16-bit Buffered Value

 

33-usecase0

Use Case 1. 32-bit Buffered Value

 

48-usecase1

 

Use Case 2. 64-bit Buffered Value

 

53-usecase2

B. Headered Values

  • 2 Fields = FieldEncodingType + Value (stored in the 16-bit, 32-bit, or 64-bit Buffer Length field)
Use Case 3. 16-bit Headered Value

 

59-usecase3

Use Case 4. 32-bit Headered Value

 

73-usecase4

Use Case 5. 64-bit Headered Value

 

78-usecase5

C. Value Constants:

  • 1 Field = FieldEncodingType (representing a specific constant value for a particular datatype stored represented an FieldEncodingType op code)
Use Case 6. 8-bit Value Constants

85-usecase6

D. Null ByteArrays

 

Use Case 7. Null-valued reference to a ByteArray

 

92-usecase7

E. Short Length ByteArrays

  • 0, 1, 2, 3 bytes in length
Use Case 8. 0-byte ByteArray

 

100-usecase8

Use Case 9. 1-byte ByteArray
105-usecase9
Use Case 10. 2-byte Byte Array
110-usecase10
Use Case 11. 3-byte Byte Array
115-usecase11

 

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

1 Comment

Filed under Uncategorized

Software Reliability Engineering (SRE): Faults, Errors, Failures and Symptom Chain

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

Draft document for discussion purposes.

Update cycle: As required – sometimes several times in a single day.

 

PSN-SRE-Fault-Error-Failure-Symptom-Model v0.1

Figure 1. Fault (Defect), Error, Failure, and Symptom Chain

Principles

P1. A Fault (or Defect) is a physical, design, or software flaw [Tschudin].

A Fault is the mechanical or algorithmic cause of an Error, while a Potential Fault is a mechanical or algorithmic construction within a system such that (under some circumstances within the specification of use of the system) that construction will cause the system to assume an erroneous state [Millier-Smith].

A Fault is a condition causes a system to fail in performing its required function [Agarwal].

P2. An Error is an incorrect behavior caused by a Fault [Tschudin].

The term Error is used to designate that part of the [system] state which is “incorrect” [Millier-Smith].

An Error is a discrepancy between the actual value of the output given by the software and the specified value of the output for a given input. That is, Error refers to the difference between the actual output of the software and the correct output. An Error is also used to refer to the wrong decision in a given case as compared to what is expected to be the right one. Error also refers to human actions that result in software containing the defect or fault [Agarwal].

P3. A Failure is the inability to perform according to a specification because of an Error [Tschudin].

A Failure of a system occurs when that system does not perform its service in the manner specified, whether it is unable to perform the service at all, or because the results and the external state are not in accordance with the specifications. [Millier-Smith].

Failure is the inability of the software system to perform a required function to its specification [Agarwal].

P4. Symptoms are external manifestations of failures [Steinder].

References

[Agarwal] B.B. Agarwal, M. Gupta, and S.P. Tayal, “Software Engineering and Testing”, Jones & Bartlett Learning, 2010.

[Millier-Smith] P.M. Millier-Smith and B. Randell, “Software Reliability: The Role of Programmed Exception Handling”, ACM, 1976.

[Steinder] Ma łgorzata Steinder and Adarshpal S.Sethi, “A survey of fault localization techniques in computer networks”, Science of Computer Programming, Volume 53, Issue 2, November 2004, Pages 165-194.

[Tschudin] Christian Tschudin, CS321/CS221: Autonomic Computer Systems, University of Basel, 2006.

[Herman] Michael Herman, “Fault-Error-Failure Chains”, https://www.facebook.com/notes/michael-herman/fault-error-failure-chains/493110544121/, Nov. 14, 2010.

 

Leave a comment

Filed under Uncategorized

#iDIDit: [OLD] An Architecture-driven Taxonomy for SSI Agents v0.5

IMPORTANT: Don’t read this version of this article about the INDY-AGENT ARM.  The official (draft) version of the INDY-AGENT ARM has moved to github: click here Appendix B – Indy Agent Architecture Reference Model (INDY-AGENT-ARM)

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

This chart below was inspired by Daniel Hardman’s 0002: Agents HIPE dated 2017-11-01 (and published 2019-01-31).  Hopefully the chart speaks for itself.  The original goal was to take Daniel’s prose and visualize it as a 2×2 matrix. I #almostDIDit :-).

Please send me your comments and feedback.  Click on each chart to enlarge and/or download it.

Recent Changes

  • Added Relay Agent.
  • Removed Thin “complexity” agent from Partial Function Agent category.
    • Thin “complexity” agent remain in the Lightweight Agent category.
  • Clarified that Thin “complexity” agent has no local state (i.e. no wallet and no local config state/files).
  • Removed Static “complexity” agent from Partial Function Agent category because it doesn’t have a Local Wallet.
    • Static “complexity” agent remain in the Lightweight Agent category.
  • Clarified that Static “complexity” agent has Local Config state.
  • Clarified that the Relay agent has a Local Wallet.
  • Added history of previous versions of this chart back to v0.3

Version 0.5

HBB-SSI-Agents v0.5

Figure 0.5. An Architecture-driven Taxonomy for SSI Agents v0.5

Version 0.4

HBB-SSI-Agents v0.4

Figure 0.4. An Architecture-driven Taxonomy for SSI Agents v0.4

Version 0.3

HBB-SSI-Agents v0.3

Figure 0.3. An Architecture-driven Taxonomy for SSI Agents v0.3

Best regards,
Michael Herman (Toronto/Calgary/Seattle)

 

Leave a comment

Filed under Uncategorized

#iDIDit: Indy-SDK getting_started.py Visualizations v0.12 (Light Table)

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

indy-sdk-getting-started-0.0 v0.10indy-sdk-getting-started-1.0 v0.10indy-sdk-getting-started-1.1 v0.10indy-sdk-getting-started-1.2 v0.10indy-sdk-getting-started-1.3 v0.10indy-sdk-getting-started-1.4 v0.10indy-sdk-getting-started-2.1 v0.10indy-sdk-getting-started-2.2 v0.10indy-sdk-getting-started-2.3 v0.10indy-sdk-getting-started-2.4 v0.10indy-sdk-getting-started-3.0 v0.10indy-sdk-getting-started-4.0 v0.10indy-sdk-getting-started-5.0 v0.10indy-sdk-getting-started-6.0 v0.10

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Best regards,
Michael Herman (Toronto/Calgary/Seattle)

Leave a comment

Filed under Uncategorized

#iDIDit: What is a DID?

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Companion Articles

DID Data Model

hbb-indy-sovrin arm v0.16-did document

Figure 1. Simplest DID Data Model

Narration

  1. [Informative] A DID Entity is a data structure comprised of a collection of key-value pairs with keys such as: id (DID), service (endpoints), authentication, publicKey, @context, etc.
  2. A DID Document is a JSON-LD serialization of a DID Entity.
  3. A DID Document has a set of attributes such as the following:
    • id (DID)
    • service (endpoints)
    • authentication
    • publicKey
    • @context
    • etc.
  4. The id (DID) attribute is the unique identifier or key for the DID Document.
    • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (or DID Document).
    • id (DID) are used to index, find, and retrieve DID Documents from the Technology Layer. id (DID) exists as an attribute of a DID Entity (and by implication, as an attribute of DID Document, the JSON-LD serialization of the corresponding DID Entity).
  5. When DID Documents, in turn, are serialized to the Indy Ledger by Indy Ledger Nodes, they are stored as a series of Indy Ledger Transactions.
  6. Edge Agents and Cloud Agents call an Indy Ledger Node to persist a DID Document to the Indy Ledger. DID Documents, specifically, are written to the Indy Ledger by the Indy Ledger Nodes using Indy NYM and Indy ATTRIB transactions.

2 Comments

Filed under Uncategorized

#iDIDit: [OLD] Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM) v0.21

IMPORTANT: Don’t read this version of this article about the INDY ARM.  The official (draft) version of the INDY ARM has moved to github: click here Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (ARM).

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Overview

The purpose of the Hyperledger Indy/Sovrin (Indy) Comprehensive Architecture Reference Model (INDY ARM) is to provide a complete, reliable, precise, visual reference for the concepts presented in the draft Decentralized Identifiers (DIDs) specification (link).

The primary audience for this article are: software people (software architects and developers), enterprise architects, and anyone new to the Hyperledger Indy project or the field of self-sovereign identity (SSI) looking to find a fast on-ramp.

The goals of the INDY ARM are:

  1. Create a complete, reliable, precise, visual model depicting Decentralized Identifiers (DIDs), DID Entities, DID Documents, and the companion Hyperledger Indy ecosystem of software projects, software components, and data elements.
  2. Enable software people to become more knowledge about and productive with the Hyperledger Indy software platform (and Sovrin governance framework) as quickly and as easily as possible.
  3. Provide a common language of discourse for describing the current state architecture as well as potential future state architectures for the Indy ecosystem and community (with particular focus emphasis on the needs and requirements of software people).

The guiding principles for the INDY ARM are:

  • Provide reliable documentation: timely, accurate, visual, and complete
  • Save as much of a software person’s time as possible
  • Leverage open source modeling specifications and tools like ArchiMate and Archi, respectively
  • Leverage enterprise architecture concepts to explain Decentralized Identifiers and Entities in a way doesn’t detract from the adoption of the INDY ARM

The drivers for the INDY ARM are:

  • The initial driver for the INDY ARM is the create a reference model to help correct a series of issues found in the draft DID specification and documented in the project’s GitHub issues list (Fall 2018).

NOTE: Some of the elements depicted in the INDY ARM have been influenced by the Verified Credentials project – particularly, the business roles and processes in the Business Layer (1), the Local Ledger State (17) in the Technology Layer – Data Model (15), and the Credential Registry Agent Node (39) in the Technology Layer (30).

Companion Articles

Tooling

Recent Feedback and Changes

  1. Ledger Agent Node changed to Ledger Node (@danielhardman)
  2. Ledger Nodes: A2A Protocol corrected to Ledger-to-Ledger Protocol (@danielhardman)
  3. Relationships added to depict A2A Protocol messaging between Edge Agents and Cloud Agents (@danielhardman)
  4. (“Identity” Layer) appended to Business Layer – Architecture (@mwherman2000)
  5. (“Edge” Layer) appended to Application Layer – Architecture (@mwherman2000)
  6. (“Cloud” and “Ledger” Layers) appended to Technology Layer – Architecture (@mwherman)
  7. Owner changed to Controller in (P2) (per CCG discussion Jan. 15 2019)
  8. Principle P7 added. See #4.
  9. Non-Fungible Entities added to Principles. (P8) and (P9) added. (P1) updated.
  10. Element (3) is now shown as copies of the same (3a) and (3b).
  11. “inanimate thing” changed to Non-Fungible Entity (10).
  12. Principle P4 reworded. DID Entity (14) redefined.
  13. Indy Ledger Local Node State changed to Indy Ledger Local Node State (Replica) (36) and (38).
  14. Indy Ledger (Journal) changed to Indy Ledger Local State (17).
  15. Indy Transactions changed to Indy Transactions (Journal) (17).
  16. Removed DID Resolver Full Node (@peacemaker).
  17. Four perspectives added to the both of the ARM.
  18. Indy Ledger Local Node State (Replica) was changed to Local Ledger State (Replica).
  19. Partitioned the DID Data Model (old 12) perspective into DID Document Data Model (44) and DID Data Model (new 12) perspectives.
  20. Added elements (44) to (50) to support change 19.

INDY ARM

Horizontally, the INDY ARM is partitioned into 4 perspectives:

  • Projects and Distributions (A)
  • Ecosystem Architecture (B)
  • DID Data Model (C)
  • DID Document Data Model (D)
  • [Verified Credentials (VC) Data Model (Future)]
  • Principles (E)

Vertically, the INDY ARM is divided into 3 architecture domains that span the 4 perspectives:

  • Business Layer (1) and (8)
  • Applications Layer (23), (44), and (12)
  • Technology Layer (30), (49), and (15)

The INDY ARM is illustrated in the following “all in” view/projection of the Indy architecture reference model. The INDY ARM is an actual queryable model – it is not a drawing (e.g. a Visio or PowerPoint diagram).

The Narration section that follows the graphic includes a description of each of the numbered bullets.

Click on the graphic to enlarge it in a separate browser tab.  Suggestion: Drag the new browser tab onto a second monitor if you have one.

HBB-Indy-Sovrin ARM v0.21

Figure 1. Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM)

NOTE: Physically, the INDY ARM is approximately 75 cm x 55 cm in size – but it is quite readable when printed on a regular-size paper – with glasses.

Narration

  1. Business Layer (“Edge” Layer) of the INDY ARM. “The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.” [ARCHIMATE]
    • The following Actor Roles are depicted in this version of the ARM: Issuer, Holder (x 2), Inspector, and Verifier. These roles are not formally defined in the draft DID specification; for the time being, they have been borrowed from the documentation related to the Verified Credentials project.
  2. An Issuer issues a self-sovereign identity (SSI) for a Something; e.g. a Birth Certificate or a Purchase Order (3). In this example, the SSI is for a Thing (10); in particular, a completed and approved Purchase Order (3) (or Birth Certificate). The Purchase Order is issued to a Holder. Both the Issuer and the Holder work for a fictitious company called Acme Corporation.
  3. SSI for a Something (e.g. Birth Certificate, Purchase Order) issued by the Issuer @ Acme (2).
  4. The Holder @ Acme accepts the SSI for the Thing (a Purchase Order) from the Issuer (2). In turn, the Holder @ Acme presents the SSI for the Purchase Order to a Holder at Baker Limited. The Holder @ Baker receives the SSI for the Purchase Order from the Holder @ Acme (4).
  5.  An Inspector @ Baker may request that the Holder @ Baker present the SSI for the Purchase Order to him/her/it. The Inspector @ Baker receives the SSI from the Holder @ Baker.
  6. The Inspector @ Baker (or any Holder) can ask for the SSI for the Purchase Order to be verified by a Verifier.
  7. There is a set of Business Services (e.g, Issue, Store, Request, Verify, Register, etc.) that support the above processes.  These Business Services are supported by services exposed by the Applications Architecture Layer (23).
  8. Business Layer – DID Data Model captures the key business-level model elements such as Actor (9), Things (10), and (Business) Processes (37).
  9. An Actor is “a business entity that is capable of performing behavior.” [ARCHIMATE]
    • Examples of Actors include Persons, Organizations, and Software Agents.
    • An Actor can have a Controller (P7). A Controller of an Actor is an Actor (P7).
  10. A Thing is Non-Fungible Entity (NFE) (P9).
    • Examples of Things include Pets (with embedded ID chips), Cars, Houses, Business Documents, Products, Assemblies, and Parts.
    • The software component of a Software Agent is a Thing. If you’re talking about Software Agent as a business entity capable of performing behavior, then the Software Agent, in this context, is an Actor.
    • A slice of a particular kind of Toast is not a Thing because it is fungible (P8) and (P9). A slice of Toast can be a Thing in the future when each slice of bread has its own bar code or serial number. A photo of a slice of Toast is a Thing because it is non-fungible (most photographs are non-fungible; hence, are Things).
    • A living cell (skin cell, blood cell, etc.) is not considered to be an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (P9) (within a single body of DNA) ..at least, not for the foreseeable future.
    • A Thing has a Controller (P2). A Controller of a Thing is an Actor (P2).
  11. (Business) Processes. Actors (Persons, Organizations, and Software Agents) participate in Processes. A Process acts on/accesses Things (e.g. a Pet (with an embedded ID chip), Car, House, Business Document, Product, Assembly, Part) to perform work.
  12. Application Layer – DID Document Data Model captures the key application-level model elements related to DID Documents such as id (DID) (13) and DID Entity (14).
  13. id (DID) exists as an attribute of a DID Entity (14) (and by implication, as an attribute of DID Document (16), the JSON-LD serialization of the corresponding DID Entity (14)).
    • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (or DID Document).
    • id (DID) are used to index, find, and retrieve DID Documents from the Technology Layer (30).
  14. A DID Entity is a data structure comprised of a collection of key-value pairs with keys such as: id (DID), service (endpoints), authentication, publicKey, @context, etc. (P4)
    • DID Entities have a set of attributes that includes the following:
      • id (DID)
      • service (endpoints)
      • authentication
      • publicKey
      • @context
      • etc.
  15. Technology Layer – DID Document Data Model captures the key technology-level model elements such as a DID Document (16).
  16. A DID Document is a JSON-LD serialization of a DID Entity (14).
    • A DID Document has a set of attributes that includes the following:
      • id (DID) (13)
      • service (endpoints)
      • authentication
      • publicKey
      • @context
      • etc.
    • The id (DID) attribute (13) is the unique identifier or key for the DID Document.
      • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (14) (or DID Document).
      • id (DID) are used to index, find, and retrieve DID Documents from the Technology Layer (30). id (DID) exists as an attribute of a DID Entity (14) (and by implication, as an attribute of DID Document, the JSON-LD serialization of the corresponding DID Entity).
  17. When DID Documents (16), in turn, are serialized to the Local Ledger State (36) and (38) by the Indy Ledger Nodes (35) and (37), they are stored as a series of Indy Ledger Transactions. Edge Agents and Cloud Agents call an Indy Ledger Node to persist a DID Document to the Indy Ledger. DID Documents, specifically, are written to the Indy Ledger by the Indy Ledger Nodes using:
    • Indy NYM transactions (50), and
    • Indy ATTRIB transactions.
  18. Technology Layer – Projects and Distributions highlights the Hyperledger (and potentially other) open source projects that design, build, and supply software components to both the Applications and Technology Layers.
  19. The Hyperledger Indy-SDK Project distribution includes two key software components used to implement an Indy Wallet (25) and (32):
    • libIndy (lower-level)
    • libVCX (higher-level)
  20. The Hyperledger Indy-Agent Project distribution is used to implement the Indy Agent functionality in the:
    • Edge Agent App (24)
    • Edge Agent Web App (28)
    • Edge Agent Lightweight App (29)
    • Cloud Agent Node (31)
    • Ledger Node (35), and
    • Credential Registry Agent Mode (39)
  21. The Hyperledger URSA Project distribution is a utility that provides implementations of the cryptographic functionality required across all of the Hyperledger projects.
  22. The Hyperledger Indy-Node Project distribution is used to implement the Indy Node functionality in the Ledger Node (35) and (37).
  23. Applications Layer (“Edge” Layer) of the INDY ARM. “The Application Layer depicts application services that support the business, and the applications that realize them.” [ARCHIMATE]
  24. The Edge Agent App 1 is an end-user application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as a Controller of Thing, or as a Guardian of another Actor (9) and (10). This is typically a mobile or a desktop app.
  25. The Edge Wallet is a mobile or desktop application component that supports the Edge Agent App’s requirements (24) for managing actual self-sovereign identities it owns.
  26. Edge Agent App 2 is an example of another Edge Agent App in the ecosystem. Communication between Edge Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (27).
  27. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26) and Cloud Agent Nodes (31) and (33).
  28. The Edge Agent Web App is an Edge Agent implemented as a server-hosted web application.
  29. The Edge Agent Lightweight App (EAPA) is a mobile or desktop application that doesn’t use a local Edge Wallet. Instead, the EAPA relies on the services of a Cloud Agent (31) and Cloud Wallet (32).
  30. Technology Layer (“Cloud” Layer) of the INDY ARM. “The Technology Layer depicts technology services such as processing, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services.” [ARCHIMATE]
  31. The Could Agent App 1 is a cloud or server-based application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as a Controller of Thing, or as a Guardian of another Actor (9) and (10). The Cloud Agent App is an alternative to using an Edge Agent App (24) and Edge Agent Wallet (25).
  32. The Cloud Wallet is a cloud or server-based technology component that supports the Cloud Agent App’s requirements (31) for managing actual self-sovereign identities it owns.
  33. Cloud Agent App 2 is an example of another Cloud Agent App in the ecosystem. Communication between Cloud Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (34).
  34. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26) and Cloud Agent Nodes (31) and (33).
  35. Ledge Agent Nodes support the requirements of Edge Agent (24) and Cloud Agent (31) applications for persisting, managing, and interacting with DID Documents (16) persisted to the Indy Ledger (36) and (17).
  36. Local Ledger State (Replica) is the distributed ledger technology that supports the persistence, management of DID Documents (16) persisted to the ledger as Indy NYM and ATTRIB transactions (17).
  37. Ledge Agent Node 2 is an example of another Ledge Agent Node in the ecosystem. Communication between Ledge Agent Nodes takes place using the Indy Ledger-to-Ledger Protocol (38).
  38. Local Ledger State (Replica) is the distributed ledger technology that supports the persistence, management of DID Documents (16) persisted to the ledger as Indy NYM and ATTRIB transactions (17).
  39. The Indy Ledger-to-Ledger Protocol is the protocol used for communication between Ledger Nodes (35) and (37).
  40. Credential Registry Agent Node is a repository for persisting, managing, and interacting with Verified Credentials. It’s implementation is based on technologies similar to those used to implement Cloud Edge Agents.
  41. DID Resolver Lightweight Node is a component that is used by Edge Agent (24) and Cloud Agent (31) applications to resolve a id (DID) (13) into a specific DID Document (16) (assuming the DID Document has been persisted to the Indy Ledger (36) and (17)). The DID Resolver Lightweight Node relies on a Ledger Node (35) and (37) to gain access to the Indy Transactions (17) on the Indy Ledger (36). The DID Document is returned as an attribute of a DID Resolver Response (43) a the DID Resolver Node.
  42. The DID Resolver Response is returned by the DID Resolver Lightweight Node (40) in response to a request to resolve a particular id (DID). The DID Resolver Response contains a didDocument attribute that, in turn, contains the corresponding DID Document (16) (assuming the DID Document exists on the Indy Ledger (36), (42) and (17)).
  43.  The DIF Universal-Resolver Project distribution is used to implement the DID Resolver Lightweight Node (41) functionality.
  44. Application Layer – DID Data Model captures the key application-level model elements related to DIDs such as SEND_NYM Message (45).
  45. A SEND_NYM message is used to create a Verifiable DID on the Ledger (17)
  46. The identifier attribute in the SEND_NYM message is associated (assigned the value) of the DID of the steward/trustee.
  47. The dest subattribute in the SEND_NYM message is associated (assigned the value) of the DID of the subject.
  48. The verkey subattribute in the SEND_NYM message is associated (assigned the value) of the verkey of the subject.
  49. Technology Layer – DID Document Data Model captures the key technology-level model elements such as the DID Ledger State (17) and Indy NYM Transaction (50).
  50. Indy NYM Transaction

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

5 Comments

Filed under Uncategorized

#iDIDit: [OLD] DID Comprehensive Architecture Reference Model (ARM) v0.8

IMPORTANT: Don’t read this version of this article about the “DID” ARM.  It’s incorrectly named – this article remains as a tombstone for the many places where this URL has been posted.  Please read: Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (ARM). (click here).

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Overview

The purpose of the DID Comprehensive Architecture Reference Model (DID ARM) is provide a complete, reliable, precise, visual reference for the concepts presented in the draft Decentralized Identifiers (DIDs) specification (link). The primary audience for this article are: software people (software architects and developers), enterprise architects, and anyone new to the Hyperledger Indy project or the field of self-sovereign identity (SSI) looking to find a fast on-ramp.

The goals of the DID ARM are:

  1. Create a reliable, precise, comprehensive, visual model depicting Decentralized Identifiers (DIDs), DID Entities, DID Documents, and the companion Hyperledger Indy ecosystem of software projects, software components, and data elements.
  2. Enable software people to become more knowledge about and productive with the Hyperledger Indy software platform (and Sovrin governance framework) as quickly and as easily as possible.
  3. Provide a common language of discourse for describing the current state architecture as well as potential future state architectures for the DID ecosystem and community (with particular focus emphasis on the needs and requirements of software people).

The guiding principles for the DID ARM are:

  • Provide reliable documentation: timely, accurate, visual, and complete
  • Save as much of a software person’s time as possible
  • Leverage open source modeling specifications and tools like ArchiMate and Archi, respectively
  • Leverage enterprise architecture concepts to explain Decentralized Identifiers and Entities in a way doesn’t detract from the adoption of the DID ARM

The drivers for the DID ARM are:

  • The initial driver for the DID ARM is the create a reference model to help correct a series of issues found in the draft DID specification and documented in the project’s GitHub issues list (Fall 2018).

NOTE: Some of the elements depicted in the DID ARM have been influenced by the Verified Credentials project – particularly, the business roles and processes in the Business architecture layer (1) and the Credential Registry Agent Node (39) in the Technology architecture layer (30).

Companion Articles and Other Resources

DID ARM Version 0.8

Horizontally, the DID ARM is partitioned into 4 perspectives:

  • Projects and Distributions (A)
  • Software Architecture (B)
  • Data Model (C)
  • Principles (D)

Vertically, the DID ARM is divided into 3 architecture domains that span the 4 perspectives:

  • Business architecture (1) and (8)
  • Applications architecture (23) and (12)
  • Technology architecture (30) and (15)

The DID ARM is illustrated in the following “all in” view/projection of the DID reference model. The ARM is an actual queryable model – it is not a drawing (e.g. a Visio diagram).

The Narration section that follows the graphic includes a description of each of the numbered bullets.

Click on the graphic to enlarge it in a separate browser tab.  Suggestion: Drag the new browser tab onto a second monitor if you have one.

hbb-indy-sovrin arm v0.8

Figure 0.8: DID Comprehensive Architecture Reference Model (ARM) v0.8

NOTE: Physically, the DID ARM is approximately 60 cm x 50 cm in size – but it is quite readable when printed on a regular sized paper – with glasses.

Narration

  1. Business Layer of the DID ARM. “The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.” [ARCHIMATE]
    • The following Actor Roles are depicted in this version of the ARM: Issuer, Holder (x 2), Inspector, and Verifier. These roles are not formally defined in the draft DID specification; for the time being, they have been borrowed from the documentation related to the Verified Credentials project.
  2. An Issuer causes a self-sovereign identity for a Something for be Issued; e.g. a Purchase Order (3). In this example, the SSI is for a Thing (10); in particular, a completed and approved Purchase Order (3). The Purchase Order is issued to a Holder. Both the Issuer and the Holder work for a fictitious company called Acme Corporation.
  3. SSI for a Something (a Purchase Order) issued by the Issuer @ Acme (2).
  4. The Holder @ Acme accepts the SSI for the Thing (a Purchase Order) from the Issuer (2). In turn, the Holder @ Acme presents the SSI for the Purchase Order to a Holder at Baker Limited. The Holder @ Baker receives the SSI for the Purchase Order from the Holder @ Acme (4).
  5.  An Inspector @ Baker may request that the Holder @ Baker present the SSI for the Purchase Order to him/her/it. The Inspector @ Baker receives the SSI from the Holder @ Baker.
  6. The Inspector @ Baker (or any Holder) can ask for the SSI for the Purchase Order to be verified by a Verifier.
  7. There is a set of Business Services (e.g, Issue, Store, Request, Verify, Register, etc.) that support the above processes.  These Business Services are supported by services exposed by the Applications Architecture Layer (23).
  8. Business Layer – Data Model captures the key business-level model elements such as Actor (9), Things (10), and Business Processes (37).
  9. An Actor is “a business entity that is capable of performing behavior.” [ARCHIMATE]
    • Examples of Actors include Persons, Organizations, and Software Agents.
  10. A Thing is inanimate entity. Things and Actors are mutually exclusive (P3). A Thing has an Owner (P2). An Owner is an Actor (P2).
    • Examples of Things include Pets, Cars, Houses, Business Documents, Products, Assemblies, and Parts.
    • The software component of a Software Agent is a Thing. If you’re talking about Software Agent as a business entity capable of performing behavior, then the Software Agent, in this context, is an Actor.
    • A slice of a particular kind of Toast is not a Thing because it is fungible. A slice of Toast can be a Thing in the future when each slice of bread has its own bar code or serial number. A photo of a slice of Toast is a Thing because it is non-fungible (most photographs are non-fungible and hence, are Things).
    • A living cell (skin cell, blood cell, etc.) would not be considered an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (within a single body of DNA) ..at least, not for the foreseeable future.
  11. Business Processes. Actors (Persons, Organizations, and Software Agents) participate in Processes. A Process acts on/accesses Things (e.g. a Pet, Car, House, Business Document, Product, Assembly, Part) to perform work.
  12. Application Layer – Data Model captures the key application-level model elements such as id (DID) (12) and DID Entity (13).
  13. id (DID) exists as an attribute of a DID Entity (13) (and by implication, as an attribute of DID Document (15), the JSON-LD serialization of the corresponding DID Entity).
    • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (or DID Document).
    • id (DID) are used to index, find, and retrieve DID Documents from the Technology Architecture layer (28/14).
  14. A DID Entity is the in-memory, application-specific object that represents a de-serialized DID Document (15). (P4)
    • DID Entities have a set of attributes such as the following:
      • id (DID)
      • service (endpoints)
      • authentication
      • publicKey
      • @context
      • etc.
  15. Technology Layer – Data Model captures the key technology-level model elements such as a DID Document (15).
  16. A DID Document is a JSON-LD serialization of a DID Entity.
    • The id (DID) attribute is the unique identifier or key for the DID Document.
    • id (DID), aka a DID, is used to index, find, and retrieve a DID Document (also see (12)).
  17. When DID Documents (16), in turn, are serialized to the Indy Ledger (36) by the Indy Ledger Nodes (37) and (17), they are stored as a series of Indy Ledger transactions. DID Documents, specifically, are written to the Indy Ledger by the Node Agent Nodes (36) and (37) using Indy NYM and Indy ATTRIB transactions.
  18. Technology Layer – Projects and Distributions highlights the Hyperledger (and potentially other) open source projects that design, build, and supply software components to both the Applications and Technology Architecture Layer.
  19. The Hyperledger Indy-SDK project includes two key software components used to implement an Indy Wallet (25) and (32):
    • libIndy (lower-level)
    • libVCX (higher-level)
  20. The Hyperledger Indy-Agent project is used to implement the Indy Agent functionality in the:
    • Edge Agent App (24)
    • Edge Agent Web App (28)
    • Edge Agent Lightweight App (29)
    • Cloud Agent Node (31)
    • Ledger Agent Node (35), and
    • Credential Registry Agent Mode (39)
  21. The Hyperledger URSA project is a utility that provides implementations of the cryptographic functionality required across all of the Hyperledger projects.
  22. The Hyperledger Indy-Node project is used to implement the Indy Node functionality in the: Ledger Agent Node (35).
  23. Applications Layer of the DID ARM. “The Application Layer depicts application services that support the business, and the applications that realize them.” [ARCHIMATE]
  24. The Edge Agent App 1 is an end-user application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as an Owner of Thing, or as a Guardian of another Actor (9) and (10). This is typically a mobile or a desktop app.
  25. The Edge Wallet is a mobile or desktop application component that supports the Edge Agent App’s requirements (24) for managing actual self-sovereign identities it owns.
  26. Edge Agent App 2 is an example of another Edge Agent App in the ecosystem. Communication between Edge Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (27).
  27. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
  28. The Edge Agent Web App is an Edge Agent implemented as a server-hosted web application.
  29. The Edge Agent Lightweight App (EAPA) is a mobile or desktop application that doesn’t use a local Edge Wallet. Instead, the EAPA relies on the services of a Cloud Agent and Cloud Wallet.
  30. Technology Layer of the DID ARM. “The Technology Layer depicts technology services such as processing, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services.” [ARCHIMATE]
  31. The Could Agent App 1 is a cloud or server-based application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as an Owner of Thing, or as a Guardian of another Actor (9) and (10). The Cloud Agent App is an alternative to using an Edge Agent App (24) and Edge Agent Wallet (25).
  32. The Cloud Wallet is a cloud or server-based technology component that supports the Cloud Agent App’s requirements (31) for managing actual self-sovereign identities it owns.
  33. Cloud Agent App 2 is an example of another Cloud Agent App in the ecosystem. Communication between Cloud Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (34).
  34. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
  35. Ledge Agent Nodes support the requirements of Edge Agent (24) and Cloud Agent (31) applications for persisting, managing, and interacting with DID Documents (16) persisted to the Indy Ledger (36) and (17).
  36. The Indy Ledger is the distributed ledger technology that supports the persistence, management of DID Documents (16) persisted to the Indy Ledger as Indy NYM and ATTRIB transactions (17).
  37. Ledge Agent Node 2 is an example of another Ledge Agent Node in the ecosystem. Communication between Ledge Agent Nodes takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (38).
  38. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
  39. Credential Registry Agent Node is a repository for persisting, managing, and interacting with Verified Credentials. It’s implementation is based on technologies similar to those used to implement Cloud Edge Agents.
  40. DID Resolver Node is a key component that is used by Edge Agent (24) and Cloud Agent (31) applications to resolve a id (DID) (13) into a specific DID Document (16) (assuming the DID Document has been persisted to the Indy Ledger (36) and (17)).

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

1 Comment

Filed under Uncategorized

#iDIDit: [OLD] End-to-end Path from a id (DID) to a Real-Life Something v0.3

IMPORTANT: Don’t read this version of this article.  The official (draft) has moved to github: click here INDY-ARM: Appendix E – DID Resolution: Path from a DID to a Real-life Something

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Companion Articles

DID End-to-end Path Version 0.3

The following graphic illustrates the path (flow) of a client app trying to: a) communicate/interact with, and/or b) access the metadata about a real-life something by using a Decentralized Identifier (id (DID)).

That is, in (almost) 10 steps or less, how to you get from an id (DID) attribute on the left to a Real-Life Something on the right?

2019-01-08 NOTE: The ultimate goal is to synthesize a simple(r) data model – not a more complex one.  However, the interim analysis phase (tearing things apart) is expectedly going to result in a data model that is visually more complex. From this analysis model, we can hopefully synthesize a data model that is simple(r).

NOTE: Click on the graphic to enlarge it.

path-id-DID-real-life-somethings v0.3.pngFigure 0.3. DID End-to-end Path v0.3

Narration

  • 0.  A DID Document contains an id (DID) attribute which is the unique identifier or key for a DID Document.
    • A Real-Life Something can be associated with more than one DID Document (and by implication, more than one id (DID)).
    • A DID Document (and its id (DID)) can only refer to one Real-Life Something.
  1. Client App (or Service) is interested in either:
    • Communicating or interacting with a Real-Life Something.
    • Gaining knowledge about a Real-Life Something. (Let’s refer this knowledge as Metadata about the Real-Life Something.)
    • NOTE: A Real-Life Something can be either a Real-Life Actor or a Real-Life Thing.
  2. Client App calls DID Resolver to retrieve the DID Document that corresponds to a particular id (DID).
  3. DID Resolver uses the id (DID) as a key (unique identifier) to retrieve the corresponding DID Document from a DID Document Repository (14).
  4. DID Resolver, in turn, returns the DID Document to the Client App.
  5. The DID Document contains a service (endpoint) attribute that points to the Software Service Endpoint for the entity where:
    • Client App can communicate or interact with a particular Virtual (Real-Life) Something (primary use case).
    • Client App can retrieve additional information about a particular Real-Life Something (aka Metadata about the Virtual (Real-Life) Something) (secondary use case and, potentially, a sub-case of the primary use case).
  6. Client App calls Software Service Endpoint to either: a) communicate/interact with, or (b) retrieve metadata about a Virtual (Real-Life) Something.
  7. [Primary Use Case] Software Service Endpoint enables Client App to communicate or interact with a particular Virtual (Real-Life) Something.
  8. Virtual Actor is a Virtual (Real-Life) Something that is associated with a Real-Life Actor (9).
  9. Real-Life Actor is a Real-Life Something that is associated with a Virtual (Real-Life) Actor (8).
  10. Virtual Thing is a Virtual (Real-Life) Something that is associated with a Real-Life Thing (11). A Virtual Thing has an Owner. The Owner of a Virtual Thing is a Virtual Actor.
  11. Real-Life Thing is a Real-Life Something that is associated with a Virtual (Real-Life) Thing (10). A Real-Life Thing has an Owner. The Owner of a Real-Life Thing is a Real-Life Actor.
  12. [Secondary Use Case] Client App retrieves Metadata Document about Virtual (Real-Life) Something from the Metadata Document Repository (15) by calling Software Service Endpoint. As in the primary use case, the Virtual (Real-Life) Something can be a Virtual Actor or a Virtual Thing.
  13. Software Service Endpoint returns the Metadata Document for the particular Virtual (Real-Life) Something to the Client App; that is, the knowledge about the Virtual (Real-Life) Something that the Client App was originally interested in Step 1.
  14. DID Document Repository is a repository of DID Documents indexed by each document’s id (DID).
  15. Metadata Document Repository is a repository of Metadata Documents.

Additional Notes

  1. An Actor is simply defined as being different from a Thing because an Actor is “a business entity that is capable of performing behavior” [ARCHIMATE].
  2. A Thing has an Owner.
  3. The Owner of a Thing is an Actor.

Questions

Please click here to provide an answer to any of the following questions or use the Indy-Semantics Rocketchat channel.

Please reference this URL in your answers: https://hyperonomy.com/2019/01/04/the-path-from-a-id-did-to-a-real-life-something/

  1. Can the data from the Metadata Document (6) be merged into/placed inside the DID Document (0)?  If so how?
    • Daniel Hardman (2019-01-07): A DID Document can contain additional sections besides those required by the spec – but I am not aware of a way to describe those sections in an interoperable way. So adding extra metadata to the DID Document would require a new convention or standard to be described.
  2. Related but separate from the first question, where does the Indy Schema effort/project artifacts (e.g. Schema Documents) fit into the above graphic?
    • Daniel Hardman (2019-01-07): “Schema” is currently used mostly to describe credentials. We could apply the concern more broadly (e.g., to A2A messages), but there is not a common understanding of anything broader.
  3. Is there a third repository (Schema Document Repository) that needs to be added to the graphic? …or is schema stored as “just another” DID Document in the DID Document Repository?  If so, in the most likely scenario, is there a separate DID Document Repository that acts as a global Schema Document Repository.  Are Schema Documents resolved through the same DID Resolver (2)?
    • Daniel Hardman (2019-01-07): Schemas for credentials are stored on the ledger – not in DID Documents, but in separate SCHEMA transactions. A schema lookup is a ledger lookup, but not a DID Document lookup. Schemas are not indexed by DID, since they do not require an endpoint or key rotation construct–but rather by an identifier that helps the ledger walk its own state trie with maximum efficiency
  4. Is the extended data for an entity stored in the original DID Document (0) (based on the Extensibility feature of a DID Dcoument) and can/does this feature explicitly rely on Schema?

Appendix A – Older Versions of the (draft) DID Data Model

Version 0.2

path-id-did-real-life-somethings v0.2

Figure 0.2. End-to-end DID Data Model v0.2

 

 

5 Comments

Filed under Uncategorized

#iDIDit: What’s more important? …the name of something or the something?

Thoughts to think about:

  • What’s more important? …the name of something or the something?
  • Under what conditions might the relative importance change?
  • What is the difference between a name, an identifier (see below for a definition), and a label?

Here’s a few examples to ponder. The discussion follows at the end of this article.

Examples

Apple (A-p-p-l-e) and Apples

Name: apple (a-p-p-l-e)

 

 

Figure 1. Somethings: (a) real apple, (b) ceramic apple, (c) apple candle, and (d) a bad apple 😉

House Numbers and Houses

Name: A specific house number

 

 

Figure 2. Somethings: (a) house with a specific numeric house number, and (b) house with script house number with a specific value

Addresses and Houses

Name: A specific address

 

 

Figure 3. Somethings: (a) house with specific numbered street address, (b) property with a specific numbered street address, and (c) house specific numeric house number and a specific numbered street address

Domain Names and DNS Resource Records

This (and the following) example are important because they represent 2 completely different, independent databases indexed/keyed by the same name: an Internet domain name.

Name: Domain name microsoft.com

DNSQUery-org3

 

DNSQUery-org0

 

DNSQUery-org1Figure 4. Somethings: DNS Resource Records for microsoft.com:
(top) single “A” record (default), (middle) all “A” records, and (bottom) all resource records

To learn more about DNS, read DNS (Domain Name Service): A Detailed, High-level Overview.

Domain Names and WHOIS Database Records

This (and the previous) example are important because they represent 2 completely different, independent databases indexed/keyed by the same name: an Internet domain name. Thank you goes to Daniel Hardman for suggesting this one.

Name: Domain name microsoft.com

whois

Figure 5. Somethings: WHOIS Database Record for microsoft.com

Github Project Respository Names

Name: https://github.com/mwherman2000/indy-arm.git

Read Git repository internal format explained  for a detailed explanation of the structure of the .git folder that is created in the local file system when a GitHub project repository is cloned using, for example:

git clone https://github.com/mwherman2000/indy-arm.git

Several additional references (links) are also included in the article.

dotgit-folder-contents

Figure 6. Somethings: GitHib Project Repository .git Local Folder

Discussion

TODO

Roles of a Name

  • noun: a-p-p-l-e
  • a partial identifier/address: a house number
  • a more complete identifier/address: the address of a house
  • a more complete identifier/address of a related entity: the address of a property that has house
  • a unique identifier: a domain name (although domain names can be used to index completely different collections – e.g. DNS Resource Records and WHOIS Database Records)

TODO

What a name is, what it is interpreted to be, and what it actually is can be are completely different things.

Possession of a something vs. control of something aren’t necessarily the same thing.

TODO

What is an “identifier”?

identifier

Figure 6. Identifier: Definition

 

 

2 Comments

Filed under Uncategorized