Draft DID spec: DID ARM (Architecture Reference Model) diagram version 0.11

Daniel and list,

I’ve updated the DID ARM (Architecture Reference Model) diagram to version 0.11.  I believe if we can get an agreeable “picture” of what we’re talking about, the correct words will come a lot easier …at least, that’s my experience in the past.
The ARM is posted here:
https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/.

Scroll down the page to the heading Version 0.11 – December 30, 2018 and start reading from there.  If you need/want more background, start reading from the top.  Here’s a copy of what I’ve written there (minus the ARM diagram)…

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.

Please reply with your thoughts and feedback.

Best regards (and Happy New Year :-)),
Michael Herman (Toronto/Calgary/Seattle)

From: Michael Herman (Parallelspace)
Sent: December 26, 2018 6:53 AM
To: 'daniel.hardman@evernym.com' <daniel.hardman@evernym.com>
Cc: public-credentials@w3.org
Subject: RE: [RESENDING] Review of the current draft DID specification

Thank you Daniel,

I’m going to continue to review the draft spec paragraph-by-paragraph and log each issue.  There are some fundamental conceptual problems that are making the draft spec very difficult to understand, let alone implement.  Once, I get to the end of the document, I can begin to summarize the core issues.  I’ve lost count but I think there are ~25 new issues so far.

I would be helpful if someone could begin commenting on the first few/5 issues starting with the oldest (https://github.com/w3c-ccg/did-spec/issues/115).

Best regards,
Michael Herman (Toronto/Calgary/Seattle)
Mobile: +1 416 524-7702

From: Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Sent: December 24, 2018 12:45 PM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: [RESENDING] Review of the current draft DID specification

What's the best way to proceed? I'm not sure... ...keep creating new issues? ...write a lengthy position paper? ... create a new PR?
IMO, it depends on the depth of the issues. If we're talking about verbiage problems, issues make sense. If we're talking about fundamental conceptual problems that run through the whole spec, then maybe a paper linked to a tracking issue might be better.

Received on Sunday, 30 December 2018 21:27:49 UTC