[Public Keys] What about when a DID Entity is a Thing ...and not an Actor?

[mwherman2000]

In https://w3c-ccg.github.io/did-spec/#public-keys, it states...

The primary intention is that a DID Document lists public keys whose corresponding private keys are controlled by the entity identified by the DID ("owned" public keys). However, a DID Document MAY also list "non-owned" public keys.

1. The above is only true when the DID Entity referenced by a DID is an Actor capable of owning "stuff" (want to avoid using the word Things here :-)).

2. What about when the DID Entity referenced by a DID is a Thing (in the Sovrin sense) ...e.g. a Pet, a Car, a House ...or in the Michael Herman extended model where a Thing can also be a Business Document, a Product, an Assembly, and/or a Part? In these cases, there must be an Owner of the DID Entity who is capable of owning the Private Keys, n'est pas?

3. Use of "entity" is confuding. See [Overview] Need for clarification in first paragraph #117

4. Misuse of "DID" ...see [PURPOSE OF THE SPECIFICATION] Is this draft specification trying to address too many topics when there should be more than 1 spec #121 (comment)

Reference: Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM) - latest version - bullets (12) thru (16) in both the diagram, Narration, and principles.

[mwherman2000]

This subsequent remark...

Each public key may include an owner property, which identifies the entity that controls the corresponding private key. If this property is missing, it is assumed to be the DID subject.

...should be reconciled with the above sentence ...more likely visa-versa. The previous paragraph should incorporate this remark.

[mwherman2000]

More generally, how are Things (e.g. pets, cars, houses) represented in "DID Document format"?

I believe an explicit section is needed to describe this use case (i.e. Things) as well as differentiate how they are the same and different from Actors (i.e. People and Organizations).

[rhiaro]

"Owner" has been replaced with "controller" as of #102 so I think that resolves 1.

Re: 2. A more involved discussion of DID Documents as descriptive (or not) of 'Things' is taking place in #148 (comment)

Your points 3. and 4. are covered by other issues as referenced.

On that basis, I'm going to close this one, but please re-open it if I've missed a point that isn't already raised elsewhere.

[mwherman2000]

@rhiaro These issues are markers for specific text in the draft DID spec that will need to be updated pending discussion/resolution of the overarching issue. Please don't close these (unless the appropriate text of this issue has been copied or moved to the referenced issue). #138 is an example where we did this earlier today (i.e. merged two related issues).

[jandrieu]

@mwherman2000 You asked

More generally, how are Things (e.g. pets, cars, houses) represented in "DID Document format"?

Neither things nor people are represented in "DID Document format".

As identifiers, DIDs can refer to anything. Person, organization, thing, concept. It doesn't matter. The DID Document describes how the DID controller can update the DID Document and how controllers of specified proofs can authenticate on behalf of the DID.

This issue should stay closed because it appears to be a misunderstanding rather than an issue with the specification.

Although, if you'd like to propose language that could help prevent others from having that same confusion, that might be a good reason to reopen it.

[mwherman2000]

@jandrieu As I've mentioned elsewhere, these issues address specific wording in the specification (quoted in each issue) ...the text either is very confusing/ambiguous ...not the type of language you want in a specification document. The specific text needs to be changed/updated.

The text of the specification needs to be crisp ...it needs to be easily read and understood; otherwise, this is will slow (is slowing) Indy/Sovrin/DID engagement and adoption by developers. I now get messages about this fact every week.

I would love to propose new text but there are some fundamental questions/issues that need to be addressed first ...someone needs to weigh in on these before text can be proposed at the nitty-gritty level:

1. [Introduction] Is the Purpose of the Draft DID spec clear and correct? Is there a defined Target Audience for the document... #157 Draft DID spec purpose and target audience
2. [Overall Scope] What is considered Normative (and in-scope), Informative (and in-scope) and just plain out of scope? #158 Normative, Informative (and in-scope) and just plain out of scope?
3. [Extensibility] references the formal concept of the Decentralized Identifiers Data Model but there is nothing in the document with this formal name/concept #151 Missing Decentralized Identifiers Data Model
4. [URIs, URLs, and URNs] Section doesn't conclude with a precise declaration of what a DID is. #155 URIs, URLs, and URNs section of draft DID spec

[rhiaro]

@rhiaro These issues are markers for specific text in the draft DID spec that will need to be updated pending discussion/resolution of the overarching issue.

I think it's preferable to have one open issue per overarching issue rather than individual ones for each chunk of text that needs an edit. When the overarching issue is resolved, the updates will take place throughout the spec. Otherwise we end up with duplicate discussions taking place (eg. #142 (comment) and #148 (comment))