[Authentication] Is Authentication the correct mechanism for specifying the ownership of a Thing?

[mwherman2000]

Is Authentication (https://w3c-ccg.github.io/did-spec/#authentication) the correct mechanism for specifying who is the authoritative owner of a Thing (e.g. pet, car, house, product, business document)?

If not, what is the correct pattern for describing a Thing in DID Document?

Cross-reference: Similar to https://github.com/w3c-ccg/did-spec/issues/142

[jandrieu]

No. It's not.

Authentication does not establish ownership (nor control), which is why authentication is a separate property.

Note, the draft needs updating to remove the misleading ownership language, to instead use "controller" to describe whoever controls the private keys that control the DID Document. See  https://github.com/w3c-ccg/did-spec/issues/153 https://github.com/w3c-ccg/did-spec/issues/108 https://github.com/w3c-ccg/did-spec/issues/101

[jandrieu]

To your other question, DID Documents don't inherently describe things.

The just describe how you prove control over an identifier.

I do believe some are using DID Documents to describe things, but IMO, this is an anti-pattern. Verifiable Credentials are a better approach for describing things.

[mwherman2000]

@jandrieu +1 for Controller (per the CCG mailing list).

I do believe some are using DID Documents to describe things, but IMO, this is an anti-pattern. Verifiable Credentials are a better approach for describing things.

I once thought VCs might work for Things but I don't believe this is so now. I believe VCs are good for managing claims about a Something ...whether it is an Actor or a Thing. I believe a DID Entity (and it's id (DID) attribute) are the anchors for any Something ...either an Actor or a Thing.

...that being said, where should/can the "data" for a Thing live/reside? ...e.g. the data content of a Purchase Order? I presume it is retrievable from the DID Entity's service endpoint?? Reference: https://hyperonomy.com/2019/01/04/the-path-from-a-id-did-to-a-real-life-something/

[jandrieu]

A DID entity is a neologism that isn't part of the spec and probably not the right framing.

A DID referent can certainly be anything, allowing a DID to refer to people, objects, even concepts.

A verifiable credential is how one would say something about that referent, by using the DID as subject. VCs can live anywhere. And can be created by anyone.

There is no canonical store of claims (verifiable or not) about subjects and there is no canonical store of "facts" about subjects. Anyone can say anything about anyone.

It is the job of the relying party to collect and evaluate whatever credentials they seek when making decisions about subjects. And it behooves holders to present the right claims to the right parties to get the services they desire.

To your example of a purchase order, where that is stored is up to the buyer and seller, and maybe regulators. You absolutely should not be putting that information on a publicly accessible DID document.

[mwherman2000]

A DID entity is a neologism that isn't part of the spec and probably not the right framing. A DID referent can certainly be anything, allowing a DID to refer to people, objects, even concepts.

I can flex on the actual name of the concept... e.g. DID Object (instead of DID Entity. It needs to be a name compatible with being an Application Layer ("Edge" Layer) concept. The entire draft DID spec suffers because this concept wasn't called out and formalized. See virtually all of the previous issues. Reference: What is a DID?

A verifiable credential is how one would say something about that referent, by using the DID as subject. VCs can live anywhere. And can be created by anyone.

VCs are something that is layered on top of the DID Entity/DID Document data model. The DID data model can't be refer to anything in the VC specification. The DID data model is foundational and needs to stand on its own.

There is no canonical store of claims (verifiable or not) about subjects and there is no canonical store of "facts" about subjects. Anyone can say anything about anyone.

I agree

It is the job of the relying party to collect and evaluate whatever credentials they seek when making decisions about subjects. And it behooves holders to present the right claims to the right parties to get the services they desire.

Ditto. Credentials aren't part of this discussion/specification. Relying parties are not part of this specification. Neither are Holders for that matter.

To your example of a purchase order, where that is stored is up to the buyer and seller, and maybe regulators. You absolutely should not be putting that information on a publicly accessible DID document.

Understood. There is no intention of storing the data/content of a Purchase Order in a DID Document (and hence not on the Ledger as well).

[jandrieu]

The DID spec has nothing to do with how you represent the deserialized DID Document in memory. That might be a useful shortcut for you, but it's a shortcut and completely out of scope.

You were the one who asked

where should/can the "data" for a Thing live/reside? ...e.g. the data content of a Purchase Order?

I'm not sure why you did, but that's what I was responding to. Where you store that is out of scope.

Respectfully, it's clear you're still figuring out what a DID actually is, so we definitely need better explanations. I appreciate your point about the ABNF, though. That section is a mess.

[mwherman2000]

Respectfully, it's clear you're still figuring out what a DID actually is, so we definitely need better explanations.

@jandrieu Thank you for the jab. Do you have any issues or concerns with the following? What would you change? How would you change it? The goal is to have a set of definitions/principles are that crisp for the new as well as experienced reader ...with a particular focus on the needs of software people (architects and developers).

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:
   1. id (DID)
   2. service (endpoints)
   3. authentication
   4. publicKey
   5. @context
   6. etc.
4. 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).
   1. The id (DID) attribute is the unique identifier or key for the DID Document.
   2. 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).
   3. id (DID) are used to index, find, and retrieve DID Documents from the Technology Layer.
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.

Reference: https://hyperonomy.com/2019/01/24/what-is-a-did/

[jandrieu]

Glad you are game enough to keep going. ;)

A few things. Here's my rev:

1. A DID Document is a JSON-LD serialization of the information required for proof-of-control, authentication, and service end-points for the referring DID.
2. A DID Document has a set of attributes such as the following:
   1. id
   2. service (endpoints)
   3. authentication
   4. publicKey
   5. @context
   6. etc.
3. id is the DID which resolves to this DID Document. This self-referential attribute assures the signed DID Document returned from resolution of the DID is the correct DID Document.
4. When DID Documents 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.

I would not mention DID Entities.

[mwherman2000]

RE: I would not mention DID Entities.

@jandrieu No, but...

• You mentioned something called a "[referring] DID" in bullet 1 without first defining it.
• You mentioned "id is the DID" in bullet 2 without first defining what a "DID" is.
• In bullet 3, you mentioned "This self-referential attribute assures the signed DID Document returned from resolution of the DID is the correct DID Document."
  • First, this wording is confusing.
  • Second, I don't believe there is any technical or stated requirement for a DID Document returned from the resolution process to be signed. Reference: Example 4 @ https://w3c-ccg.github.io/did-spec/#did-subject
  • Third, if the DID Document was signed, it's not an artifact of the resolution process (which one could imply from your wording). For the DID Document to be signed, it needs to contain the appropriate JSON name-value pairs placed inside the DID Document before it is serialized to a Ledger. The resolution process simply returns whatever was placed on the Ledger (for this DID).

I stand by my DID data model and narration (explanation).

"Take 2"?

[jandrieu]

This is being addressed in part in https://github.com/w3c/did-spec/issues/4 (the question of what does it mean to specify something in the Authentication section).

It is also advocated as best practice that a DID Document should not and is not used to describe anything other than the mechanisms for interacting with the Subject securely (including cryptographic authentication and service endpoints). General characteristics of things should be communicated in VCs or elsewhere.

We've moved this to the DIDWG repo to get the sense of the working group of that underlying issue.