Category Archives: Uncategorized

#iDIDit: Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM) v0.19

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 Indy Ledger 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.

INDY ARM

Horizontally, the INDY ARM is partitioned into 4 perspectives:

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

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

  • Business Layer (1) and (8)
  • Applications Layer (23) and (12)
  • Technology Layer (30) 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.19

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

NOTE: Physically, the INDY ARM is approximately 60 cm x 50 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 Data Model captures the key application-level model elements such as id (DID) (12) 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 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 Indy Ledger (36) 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 and Indy ATTRIB transactions (17).
  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. 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 Ledger-to-Ledger Protocol (38).
  38. The Indy Ledger-to-Ledger Protocol is the protocol used for communication between Ledger 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 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 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.
  41. DID Resolver Full 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 Full Node does not rely on a Ledger Node to gain access to the journal of Indy Transactions (17) on the Indy Ledger (36). A full node maintains its own copy of the Indy Ledger local state. The DID Document is returned as an attribute of a DID Resolver Response (43) by a DID Resolver Node.
  42. Indy Ledger local state for a DID Resolver Full Node (41). A full node maintains its own copy of the Indy Ledger local state. The Indy Ledger local state is a local copy/replica of the journal of Indy Transactions (17).
  43. The DID Resolver Response is returned by the DID Resolver Lightweight Node (40) or a DID Resolver Full Node (41) 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)).
  44.  The DIF Universal-Resolver Project distribution is used to implement the DID Resolver Node functionality – both in the lightweight node (40) and the full node (41).

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

4 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: End-to-end Path from a id (DID) to a Real-Life Something v0.3

Draft document for discussion purposes.

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?
    • Michael Herman (2019-01-15): You don’t want to store extended data (in the sense I intended) because everything in the DID Document becomes persisted data on the Indy Ledger (which is not desirable).

Simplest DID Data Model

If you prefer the following simplest DID Data Model (from the Technology Layer), that’s OK too. 🙂

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

Figure 2. Simplest DID Data Model

Narration

  1. A DID Document is a JSON-LD serialization of a DID Entity.
  2. A DID Document has a set of attributes such as the following:
    • id (DID)
    • service (endpoints)
    • authentication
    • publicKey
    • @context
    • etc.
  3. 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).
  4. 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.
  5. 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.

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

 

 

4 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?

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

Examples

Apple 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:

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

 

2 Comments

Filed under Uncategorized

DNS (Domain Name Service): A Detailed, High-level Overview

How’s that for a confuding title?  In a recent email discussion, a colleague compared the Decentralized Identifier framework to DNS …suggesting they were similar.  I cautiously tended to agree but felt I had an overly simplistic understanding of DNS at a protocol level.  That email discussion led me to learn more about the deeper details of how DNS actually works – and hence, this article.

On the surface, I think most people understand DNS to be a service that you can pass a domain name to and have it resolved to an IP address (in the familiar nnn.ooo.ppp.qqq format).

domain name => nnn.ooo.ppp.qqq

Examples:

  1. If you click on Google DNS Query for microsoft.com, you’ll get a list of IP addresses associated with the Microsoft’s corporate domain name microsoft.com.
  2. If you click on Google DNS Query for www.microsoft.com, you’ll get a list of IP addresses associated with the Microsoft’s corporate web site www.microsoft.com.

NOTE: The Google DNS Query page returns the DNS results in JSON format. This isn’t particular or specific to DNS. It’s just how the Google DNS Query page chooses to format and display the query results.

DNS is actually much more than a domain name to IP address mapping.  Read on…

DNS Resource Records

There is more to the DNS Service database than these simple (default) IP addresses.  The DNS database stores and is able to return many different types of service-specific IP addresses for a particular domain.  These are called DNS Resource Records. Here’s a partial list from http://dns-record-viewer.online-domain-tools.com:

Most APIs only support the retrieval of one Resource Record type at a time (which may return multiple IP addresses of that type). Some APIs default to returning A records; while some APIs will only return A records. Caveat emptor.

To see a complete set of DNS Resource Records for microsoft.com, click on DNSQuery.org query results for microsoft.com and scroll down to the bottom of the results page …to see the complete response (aka authoritative result). It will look something like this:

DNSQUery-org1

Figure 1. DNS Resource Records for microsoft.com: Authoritative Result

NOTE: The Resource Record type is listed in the fourth column: TXT, SOA, NS, MX, A, AAAA, etc.

DNS Protocol

The most interesting new information/learnings is about the DNS protocol.  It’s request/response …nothing new here.  It’s entirely binary …to be expected given its age and the state of technology at that time. Given how frequently DNS is used by every computer on the planet, the efficientcy of a binary protocol also makes sense. The IETF published the original specifications in RFC 882 and RFC 883 in November 1983.

The new part (for me) is that an API typically doesn’t “download” the entire authoritative set of DNS Resource Records all at once for a particular domain, the most common API approach is to request the list of IP addresses (or relevant data) for a particular Resource Record type for a particular domain.

The format of a sample DNS request is illustrated in the following figure:

messages-requestFigure 2. Sample DNS Request [CODEPROJECT]

It’s binary. The QTYPE (purple cells on the right side) defines the type of query. In this case 0x0F is a request for an MX record; hence, this is a request for the data that describes microsoft.com’s external email server interface.

NOTE: The “relevant data” isn’t always an IP address or a list of IP addresses. For example, response may include another domain name, subdomain name, or, in some cases, simply some unstructured text (as far as the DNS specification is concerned).

Here is a typical response for the above sample request:

messages-responseFigure 3. Sample DNS Response [CODEPROJECT]

The response in turn is also binary. In this case, DNS has responded with 3 answers; that is, 3 subdomain names: mailc, maila, and mailb – each with a numerical preference (weight).

The ANY Resource Record Type

There is also a “meta” Resource Record Type called ANY that, as you might guess, requests a collection of all of the different Resource Record type records.  This is illustrated in Figure 1 above.

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

2 Comments

Filed under Uncategorized

#iDIDit: Trusted Digital Web v0.3

Click the figures to enlarge them.

Trusted Digital Web 0.3

Trusted Digital Web v0.3.png

Trusted Digital Web 0.2

Trusted Digital Web v0.2.png

2 Comments

Filed under Uncategorized

#iDIDit: [OLD] Decentralized Identifiers (DIDs) Architecture Reference Model (ARM)

IMPORTANT: Don’t read this version of this article about the “DID” ARM.  This is an old article but it remains here 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
December 2019

Draft Versions for Discussion Purposes Only

QUESTION: Are these diagrams precise, accurate, and complete? In particular, are the components and relationships in the Technology/Infrastructure Architecture layer precise, accurate, and complete? Please add a comment to the end of this article or email me at mwherman@parallelspace.net.

Context

The Decentralized Identifiers (DIDs) architecture reference model diagrams that follow were created to support the following discussion…

From: Michael Herman (Parallelspace)
Sent: December 20, 2018 10:01 AM
To: public-credentials@w3.org
Subject: Review of the current draft DID specification

I’ve recently started a detailed review of the current draft DID specification document and to be direct, I have found even the first few sections to be quite imprecise and confuding.

I’ve started creating a new GitHub issue every time I’ve encountered a problem. 11 issues so far and I’m barely into section 2.

I’m reviewing the draft spec from the perspectives of an Enterprise Architect and experienced blockchain developer. Most of the issues relate to a lack of precision in the use of key concepts and terminology …as well as unnecessary IMHO overloading of these key concepts/terms …things that should be prohibitive in a spec document.

That’s a bit of a brutal introduction… But those who have met me (in Basel for example) understand my proper passion around these topics.

I also understand there is a rush to advance this document from a Community draft specification to something with a more formal status. I honestly don’t think the document is ready …but I don’t know what the “bar” is.

What’s the best way to proceed? I’m not sure… …keep creating new issues? …write a lengthy position paper? … create a new PR?

Your thoughts?

Architecture Reference Model Diagrams

These diagrams are part of a larger effort to create an architecture reference model for the entire Hyperledger Indy software platform and Sovrin governance model.  The achieve this goal, a deep and precise of the draft Decentralized Identifiers (DIDs) specification is required.  I appreciate all of your help and input.  …Michael

p.s. These diagrams will be updated regularly – sometimes a couple times per day.

p.p.s. The Open Group’s ArchiMate 3.0 visual design notation for Enterprise Architecture was used to create these diagrams using Archi, the open source ArchiMate modeling tool.

Click on any of these diagrams to enlarge them.

Version 0.14 – January 1, 2019

Relative to version 0.11, version 0.14 recognizes Software Agents as Actors. Scroll down to Version 0.11 – December 30, 2018 for the most complete set of architectural principles.

DID Logical Architecture v0.14Figure 0.14 Decentralized Identifiers (DIDs) – Architecture Reference Model (ARM) v0.14 – January 1, 2019

Version 0.11 – December 30, 2018

The updates in version 0.11 of the Decentralized Identifiers (DIDs) ARM (architecture reference model) are limited to the Business Architecture Layer; more specifically, clarifying to roles and relationships between:

  • Actors (Persons and Organizations), and
  • Things (Pets, Cars, Houses, Business Documents, Products, Assemblies and Parts).

The role of Actor in the model is a key learning that came out of the Basel workshop.

I’ve taken the idea a step further to find a proper “place and set of relationships” for the Sovrin concept of “Things”.  I believe I’ve (successfully?) done that but am looking for feedback/consensus about these ideas.  They are presented visually in the diagram below.

The new Business Architecture basic principles are:

  1. An Actor is either a Person or an Organization.
  2. Each Person or Organization has one or more SS Digital Identities associated with it.
  3. Actors (Persons and Organizations) participate in Processes.
  4. A Process acts on/accesses Things (e.g. Pet, Car, House, Business Document, Product, Assembly, Part) to perform work.
  5. Business Documents, Products, Assemblies and Parts are different from the traditional or generic Sovrin concept of a Thing (e.g. Pet, Car, House).
  6. Each Thing has one or more SS Digital Identities associated with it.

To bridge from previous versions of the ARM (see below), the following Application Architecture basic principles also apply:

  1. A DID Document is a JSON-LD serialization of a DID Entity.
  2. A DID Entity is the in-memory, application-specific object that represents a de-serialized DID Document.
  3. A DID Entity is what application developers work with (program against) at the Application Architecture level of an app.
  4. DID Entities have a set of attributes such as the following:
    • id (DID)
    • service (endpoints)
    • authentication
    • publicKey
    • @context
    • etc.
  5. “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).
  6. 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).
  7. DIDs are used to index, find, and retrieve DID Documents from the Technology/Infrastructure Architecture layer.
  8. DID Documents represent the primary object type that is exchanged between the Application Architecture layer and the Technology/Infrastructure layer.

DID Logical Architecture v0.11Figure 0.11 Decentralized Identifiers (DIDs) – Architecture Reference Model (ARM) v0.11 – December 30, 2018

 

Version 0.10 – December 21, 2018DID Logical Architecture v0.10Figure 0.10 Decentralized Identifiers (DIDs) – Architecture Reference Model (ARM) v0.10 – December 21, 2018

 

Version 0.9 – December 21, 2018

DID Logical Architecture v0.9.pngFigure 0.9 Decentralized Identifiers (DIDs) – Architecture Reference Model (ARM) v0.9 – December 21, 2018

 

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

2 Comments

Filed under Uncategorized

Confuding, Confuded, and Confudsion

: synonyms confusing. Result of spreading fear, uncertainty and doubt in the minds of new project participants. “The specification was confuding to most new developers.”

: synonyms confused. An adjective describing the feelings of fear, uncertainty and doubt about a topic or concept. “The developers became confuded while trying to decipher the meaning, intent and practical application of the specification”.

: synonyms confusion. A state of mind resulting from having feelings of fear, uncertainty and doubt about a topic. “The document created a lot of confudsion with respect to the meaning, intent and practical application of the specification”.

 

3 Comments

Filed under Uncategorized

Refactoring UBL 2.2 business documents for enacting business processes on the blockchain [WIP]

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

The purpose of this article is to describe the background and rationale for set of proposed extensions to the UBL 2.2 business document specification to make UBL schema better suited for  creating distributed business applications on the blockchain. The proposed set of extensions is referred to as the Universal UBL Extensions.

Hyperonomy Business Blockchain (HBB)

Hyperonomy Business Blockchain (HBB) is a horizontal software applications platform for supporting standards-based, end-to-end, general-purpose, trusted business processing on a global scale.

HBB Standards

A key characteristic of HBB is its reliance on prevailing standards for:

  1. Business document definitions (business document schema)
  2. Executable business process definitions (workflow template definitions)
  3. Digital identity
  4. General-purpose, programmable blockchain platforms
  5. Microsoft .NET Core Common Language Runtime (CLR) for virtual machine support

For business document schema, HBB is reliant on the UBL 2.2 (Universal Business Language) specification from the OASIS group.

For defining workflow templates, HBB is reliant on the BPMN 2.0 specification from the Object Management Group (OMG).

For digital identity support, HBB is leveraging:

Hyperledger Indy is a distributed ledger, purpose-built for decentralized identity. It provides tools, libraries, and reusable components for creating and using independent digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other “silo.” [INDY]

Sovrin is a decentralized, global public utility for self-sovereign identity. Self-sovereign means a lifetime portable identity for any person, organization, or thing. It’s a smart identity that everyone can use and feel good about. Having a self-sovereign identity allows the holder to present verifiable credentials in a privacy-safe way. These credentials can represent things as diverse as an airline ticket or a driver’s license. [SOVRIN]

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document contains at least three things: cryptographic material, authentication suites, and service endpoints. Cryptographic material combined with authentication suites provide a set of mechanisms to authenticate as the DID subject (e.g., public keys, pseudonymous biometric protocols, etc.). Service endpoints enable trusted interactions with the DID subject. [DID]

[Sovrin] DIDs are created, stored, and used with verifiable claims. [The Sovrin DID Method Specification] covers how these DIDs are managed. It also describes related features of Sovrin of particular interest to DID owners, guardians, and developers. [SOVRINREGISTRY]

For general-purpose, programmable blockchain platform support, HBB is reliant on:

  • Stratis Platform for creating highly composable, performant, reliable, and trustworthy custom blockchain platforms, and
  • .NET Core Common Language Runtime (CLR) for virtual machine support.

The Stratis Full Node is the engine that powers the Stratis blockchain network. A future-proof and environmentally sustainable consensus protocol, which uses a Proof-Of-Stake (PoS) algorithm, drives each Full Node in the network.

.NET Core is an open-source, general-purpose development platform maintained by Microsoft and the .NET community on GitHub. It’s cross-platform (supporting Windows, macOS, and Linux) and can be used to build device, cloud, and IoT applications.

UBL (Univeral Business Language) Specification

UBL documents are conceived for the purpose of interchange between disparate systems to replace existing trade documents. [HOLMAN1]

UBL is an OASIS specification that defines schema for the 81 most common digital business documents used in supply chain or other online commerce scenarios. The current version of the UBL specification is known as OASIS Universal Business Language version 2.2.

The OASIS Universal Business Language (UBL) is intended to help solve these problems by defining a generic XML interchange format for business documents that can be restricted or extended to meet the requirements of particular industries. Specifically, UBL provides the following [UBL22]:

  • A suite of structured business objects and their associated semantics expressed as reusable data components and common business documents.
  • A library of XML schemas for reusable data components such as “Address”, “Item”, and “Payment”—the common data elements of everyday business documents.
  • A set of XML schemas for common business documents such as “Order”, “Despatch Advice”, and “Invoice” that are constructed from the UBL library components and can be used in generic procurement and transportation contexts.

A key premise of a UBL business document schema is that is complete, standalone, physical representation of the underlying conceptual business or application object. The primary intended purpose of documents conformant with the UBL specification is: electronic document exchange and rendering/printing.

An example receiver application is a print facility that can print any instance of a given UBL document type without having to perform any calculations nor need even know the underlying calculation model.

For the purposes of this article, the following UBL Invoice schema serves as the primary use case. The first page of  the UBL Invoice schema looks like the following.

UBL-InvoiceFigure 1. UBL Invoice Schema Example (Partial)

Each one of the 81 UBL business document schema is a complete, holistic representation of a particular business document (e.g. Invoice, Business Card, Bill of Lading, Order, Request for Quotation, Forwarding Instructions, etc.).

Blockchain Requirements for UBL Business Documents

To represent UBL Business Documents more effectively and more efficiently for use in blockchain-based distributed business applications, the following requirements are important:

  1. Extremely compact and efficient binary serialization of each entity (and subentity)
  2. Refactoring/normalization/decomposition of large aggregated entities into small, separate, external subentities (e.g. 5-10 properties per entity) aggregated together by-reference (vs. by-value)
  3. Re-use of existing (non-fungible) subentities wherever and whenever possible to conserve space and eliminate replication and redundancy wherever and whenever possible
  4. Secure, permanent, immutable, and trusted (“trusted in a trust-less way”)

Detailed Requirements

Universal UBL (UUBL) is a set of extensions to (or superset of) the UBL 2.2 specification that provides enhanced support for storing and interacting with digital business documents on a digital identity/general-purpose blockchain hybrid applications platform.  The UUBL extensions are an answer to the 4 blockchain requirements outlined in the previous section.

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.

Requirement 2. Refactoring/Normalization/Decomposition

By definition the UBL schema definitions are both complete and monolithic – they completely description a particular digital business document in its entirety.

For storage on a blockchain and for direct reference by (a) code running in a traditional smart contact or (b) a new generation of business process workflow templates running directly on a workflow-engine-based virtual machine, the potentially large size of a typical, monolithic UBL business document makes them prohibitively large and prohibitively expense to store, process, and manage on a typical general-purpose programmable blockchain.

A replicable solution for refactoring/normalizing/decomposing each UBL document schema into a collection of subentity schema is need.  A solution is proposed by the author in the section Universal UBL: Extensions for the Blockchain.

Requirement 3. Re-use of Subentities

Closely couple with Requirement 2, is the re-use of existing subentities wherever and whenever possible to conserve space and eliminate replication and redundancy wherever and whenever possible. Backing this requirements is the knowledge that most every-day business documents (i.e. those representable by the 81 UBL business document schema) are in fact permanent (subject an organization’s retention policies), immutable, constant-valued documents once they are created.  The simplest example is Waybill.  Once you have created your (Federal Express or DHL) Waybill, it is a permanent, immutable, constant-valued business document once it has been created and printed (and is not destroyed before it is used).

Given these characteristics of business document in general (and UBL business documents in particular), business documents represent a proper subset of a broader class of entities called Non-Fungible Entities (or NFEs).  Another significant class of NFEs are NFTs (Non-Fungible Tokens) …of which, the Ethereum-based CryptoKitties are the penultimate example.

The author’s thesis is that, given business documents stature as NFEs, business documents (and NFEs generally) can be implemented and best managed using the emerging digital identity, in particular the self-sovereign identity (SSI) platforms, that are “coming to market”.

The best platform, from amongst these, in the author’s opinion, is the Hyperledger Indy SSI software platform operated under the stewardship of the Sovrin SSI governance framework.

Requirement 4. Secure, Permanent, Immutable, Trusted and Friction-less

This set of adjectives, plus a few others, symbolize and capture the essence of the intersection between the world of digital business documents and the world (sometimes what I call the religion) of the blockchain.

It is in this intersection between digital business documents and the blockchain that the greatest opportunities lie for supporting friction-less, trusted, standards-based end-to-end business process on a global scale.

Universal UBL: Extensions for the Blockchain

The following sections detail the envisioned solution for each of the above 4 requirements.

Requirement 1. Compact and Efficient Binary Serialization

Solution: SerentityData Variable-Byte Entity Serialization

The goal of the serentitydata project is to provide support the design and development of enterprise and Internet class distributed applications using blockchain technologies. This includes tools and libraries (code), frameworks, how-to documentation, and best practices for enterprise distributed application development. The serentitydata project has a specific focus on the robust and efficient design and management of immutable, historized, and auditable data stored on a blockchain.

TODO

Requirement 2. Refactoring/Normalization/Decomposition

Solution: Refactoring/Normalization/Demposition of UBM 2.2 Schema into Subentities Supported by the W3C DID (Decentralized Identifiers) Specification.

TODO

UUBL-InvoiceFigure 2. UUBL Invoice Schema Example
<ucbc:DID>did:hbb:00AE77FF-13F5-4268-A8EE-BF62FE904F50</ucbc:DID>

TODO

UUBL-AccountingSupplierPartyFigure 3. UUBL Accounting Supplier Party Schema Example
<ucbc:DID>did:hbb:00AE77FF-13F5-4268-A8EE-BF62FE904F51</ucbc:DID>

 

TODO

UUBL-PartyFigure 4. UUBL Party Schema Example
<ucbc:DID>did:hbb:00AE77FF-13F5-4268-A8EE-BF62FE904F53</ucbc:DID>

TODO

UUBL-PostAddressFigure 5. UUBL Postal Address Schema Example
<ucbc:DID>did:hbb:00AE77FF-13F5-4268-A8EE-BF62FE904F54</ucbc:DID>

TODO

Requirement 3. Re-use of Subentities

TODO

Requirement 4. Secure, Permanent, Immutable, Trusted and Friction-less

TODO

TODO

References

Appendix A – Ken Holman – Personal Communication – December 2, 2018 6:38 PM

From: G. Ken Holman <g.ken.holman@gmail.com>
Sent: December 2, 2018 6:38 PM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net>; William Olders <wolders@xalgorithms.org>; stephenrowlison@gmail.com
Cc: Michael Blanchet <michael.blanchet@gmail.com>; Larry Strickland <lstrickland@dkl.com>
Subject: RE: Introduction by Ken between Michael and Bill – Business Document “Facts”

At 2018-12-02 14:13 +0000, Michael Herman (Parallelspace) wrote:
Ken, Bill and Stephen, I do have a question…

I’ll take on the answer … this is the area of my contribution to the project. I’ve copied Michael and Larry just for their curiosity as I think they’ll find this discussion interesting.

In the <http://docs.oasis-open.org/ubl/os-UBL-2.2/xml/UBL-Invoice-2.1-Example.xml>http://docs.oasis-open.org/ubl/os-UBL-2.2/xml/UBL-Invoice-2.1-Example.xml example, if the value of the <cac:AccountingSupplierParty. cac:PostalAddress component/subelement of an Invoice already exists as a “separate document” somewhere addressable by a URL (or indirectly locatable via a URN)…

* Is there a standard/recommended/off-the-wall way for a specific Invoice to specify the value of AccountingSupplierParty. PostAddress by reference …instead of “by value” (i.e. instead of the long-hand, replicated approach seen in the example)?

No. That isn’t the UBL way. In UBL all values must be manifest and redirecting selective components to copies found elsewhere in the document is not accommodated:

http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html#S-MANIFEST-VALUES

Of course it is necessary to point out to other documents, but there is, say, no XPath or other addressing mechanism built into the UBL serialization to accommodate shared fragmentation.

The UBL committee has been standardizing a semantic library of the business documents and their business objects, and a number of syntactic serializations of those semantics have been specified, XML being the only normative one.
Others in ASN.1 and JSON are available, but they are not normative.

* What does/would an acceptable XML “syntax” look like/might look like?

I would use XPath for addressing a point into an XML document. XPointer would be used if you wanted to point to a range of items found in an XML document. Within an XML document I would use ID/IDREF, but those properties are not available in UBL.

Not many people realize that UBL was not built using XML/XSD, it was built using CCTS. CCTS doesn’t have ID/IDREF concepts.

* Is there standard terminology for referring generally to a subcomponent/subelement of an Invoice (or any other) UBL document? I’m currently using the term Fact to refer to each of the subcomponents (applied recursively if necessary)?

No such terminology is used within the committee … such a concept isn’t leveraged because the syntax is but a straightforward manifest serialization of the semantic components. This is best for interchange between independent platforms and also for things such as rendering.

A recipient of a UBL document should have everything they need without needing to calculate anything … the calculus of the values cannot be assumed to be known by the recipient.

UBL documents are conceived for the purpose of interchange between disparate systems to replace existing trade documents.

Appendix B – NEO-NATION and HYPERONOMY BUSINESS BLOCKCHAIN Infographic

TODO

NEO-NATION1

TODO

Appendix C – SerentityData Field Encoding

TODO

SerentityData1.pngFigure C.1: Serentity Field Encoding Table

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 C.2: SerentityDapp.Perfmon Data Model – Onchain [blockchain] Performance Monitoring and Recording Example

 

 

 

Leave a comment

Filed under Uncategorized

Are Canadian banks trafficking in the digital identities of millions of Canadians?

In light of the recent Zuckerberg testimony in front of the U.S. Congress, the May 2018 deadline for organizations to implement General Data Protection Regulation (GDPR) data privacy regulations[7], and the imminent release of the SecureKey verify.me digital identity system, an important question is:

Are Canadian banks guilty of trafficking in, monetizing, and profiting from the digital identities of millions of Canadians, with the support of IBM and SecureKey as their key technology partners?

On October 18, 2016, SecureKey Technologies Inc., a Toronto-based provider of identity and authentication solutions, announced that it has raised:

“$27 million CAD in growth capital to fund the commercial rollout of a privacy-enhancing digital identity network. Teaming up with SecureKey on this initiative and participating in the funding round are leading financial institutions: BMO Bank of Montreal, Bank of Nova Scotia, CIBC, Desjardins, Royal Bank of Canada and TD.”[1]

On March 20, 2017, IBM and SecureKey announced that they were:

“working together to enable a new digital identity and attribute sharing network based on IBM [Hyperledger Fabric] Blockchain.”[2]

Subsequently in early 2018, SecureKey released two additional documents[4][5] that describe both the business model and technology platform for the verify.me digital identity system. Verify.me is SecureKey’s IBM Hyperledger distributed ledger (blockchain) based digital identity system supported by Canada’s largest 5 banks (as well as other institutions):

  • The Toronto-Dominion Bank (TD Bank)
  • Bank of Montreal (BMO)
  • Canadian Imperial Bank of Commerce (CIBC)
  • Bank of Nova Scotia (Scotiabank)
  • Royal Bank of Canada (RBC)

Additional details on the verify.me digital identity system were also presented at the Australian Payments Network conference in August, 2017[3].

The Business Model

The most concerning part of this partnership between SecureKey, IBM, and the Canadian banks is the partnership’s intent to monetize and profit from the trafficking of digital identities of individual Canadians based on the following and similar excerpts from [4][5]:

The Business Model-Healthcare

Figure 1. SecureKey verify.me Business Model

The SecureKey documents’ rationale for SecureKey and the Canadian banks to pursue this business model was driven by a perceived threat by the banks from many fronts including encroachment by non-banking businesses into the domain of the Canadian banks and pending new regulations (e.g. PSD2).

Monetization of data was clearly important

Figure 2. Banking industry rationale for monetizing customers’ digital identites

The Technology Platform

IBM is providing SecureKey with the Hyperledger products, technologies, services, and know-how to create what is, in effect, a digital identity dark web [8] for the Canadian banking industry to engage in trade of their customers’ digital identity information with SecureKey and SecureKey’s digital identity requester clients.

The primary technology platform is the open source Hyperledger Fabric v1.0 project – an open-source distributed ledger project used almost exclusively for private and consortium applications[6].

The following diagram represents a consolidation of the information presented in the SecureKey references mentioned at the end of this article.

SecureKey-verify.me

Figure 3. SecureKey verify.me Digital Identity Dark Web

SecureKey brokers digital identity information requests (claims) from Digital Identity Information Requesters.  SecureKey satisfies these claims (requests for digital identity information) by using the SecureKey digital identity dark web it has implemented with its banking partners (Digital Identity Information Providers) using the Hyperledger technology.

Information and Privacy Risk

SecureKey’s February 2018 documents highlight initial set of digital identity information (digital assets) that will be provided by the Digital Identity Information Providers as illustrated in the following diagram[4][5].

SecureKey-Digital Assets

Figure 4. Information and Privacy Risk

Without adequate governance and government regulation, once in place, the verify.me digital identity system can be used to satisfy any digital identity claim from any requester including health information, additional financial information, and other personal data.  A lot is at stake for individual Canadians.

Conclusions

Why are the Canadian banks and SecureKey being allowed to monetize and profit from individual Canadians’ digital identity information? A person’s digital identity is like their digital heart and digital soul. Individual Canadians need to own and control both of these – all of their digital identity data.  The role of industry and government should be to act as validators of each person’s digital identity …and no more.  Who is watching out for the future of Canadians?

References

[1] SecureKey Technologies Inc., “Press Release: SecureKey Completes $27 Million Strategic Investment Round”, https://securekey.com/press-releases/securekey-completes-27-million-strategic-investment-round/, October 18, 2016.

[2] SecureKey Technologie Inc., “Press Release: IBM and SecureKey Technologies to Deliver Blockchain-Based Digital Identity Network for Consumers”, https://securekey.com/press-releases/ibm-securekey-technologies-deliver-blockchain-based-digital-identity-network-consumers/, March 20, 2017.

[3] Australian Payments Network, “Digital Identity” Session, https://www.slideshare.net/AusPayNet/australian-payments-network-digital-id-session, slides 41-59, August 2017.

[4] SecureKey Technologies Inc., “Identity Now (Banking Edition)”, http://securekey.com/wp-content/uploads/2017/07/SecureKey_Whitepaper_Banking_Final_Feb2018.pdf, February 2018.

[5] SecureKey Technologies Inc., “Identity Now (Telcom Edition)”, http://securekey.com/wp-content/uploads/2017/07/SecureKey_Whitepaper_Telecom_FINAL_Feb2018.pdf,  February 2018.

[6] Wikpedia, “Hyperledger”, https://en.wikipedia.org/wiki/Hyperledger, Last edited on 12 April 2018, at 16:12.

[7] European Commission, “Data protection: Rules for the protection of personal data inside and outside the EU”, https://ec.europa.eu/info/law/law-topic/data-protection_en, January 2018.

[8] Wikipedia, “Dark Web”, https://en.wikipedia.org/wiki/Dark_web, Last edited on 21 April 2018, at 15:12.

 

Leave a comment

Filed under Uncategorized