Proposed Appendices on DID Identification Architecture

[talltree]

Several current issues including #355 and #348 (and W3C CCG Security Vocab issue 45) depend on understanding how DID identification architecture works from a graph and semantic model standpoint. This is not currently explained anywhere in the spec. However it has been argued that this content is needed someplace in the spec in order to support a full understanding of how to use DIDs.

Since there isn't another section that feels like a natural home for this content (which is entirely explanatory in nature and contains several diagrams), it has been proposed to add it as one or more appendices to the spec. I have draft three such appendices for this purpose. I have not yet submitted them as PRs yet because it is a lot of content that is more easily reviewed and discussed first in a traditional document format. So all three are currently in a single Google doc. The direct links are:

• Appendix A: What Does a DID Identify?
• Appendix B: DID Controllers and DID Subjects
• Appendix C: Multiple DID Controllers

I have attached this PDF of the current Google doc for anyone who does not have access to Google docs.

Although you can make comments directly in the Google doc (and some already have), it would be best for visibility, access, and archiving to carry on any substantial discussions here, in this issue thread. I will start by answering a few of the comments that have already been made in the Google doc.

Lastly, many thanks to @peacekeeper for helping to think through and review early drafts of this content. He and I have been struggling with these issues regarding Internet identifiers for 15+ years together, and on these questions he is wise way beyond his years.

[OR13]

@kdenhartog what is incorrect?

alice verificationMethod #key-0 vs alice verificationMethods #key-0

one of these reads much more correctly... objects was an option, see: https://w3c.github.io/wot-thing-description/#property-serialization-json

that ship has sailed.

[kdenhartog]

@kdenhartog what is incorrect?

alice verificationMethod #key-0 vs alice verificationMethods #key-0

one of these reads much more correctly... objects was an option, see: https://w3c.github.io/wot-thing-description/#property-serialization-json

that ship has sailed.

The discussion about verficationMethod vs verificationMethods is a bit different from what I'm proposing here. In the previous post I was discussing the semantics of the property term controller and how it causes confusion of whether the property is referring to the DID Document or the DID Subject.

As for the usage of object, I don't mean object in the sense of a JSON object. I meant it in the sense of the term of object in RDF. Do to the semantics of what a did represents (it's an identifier for the DID Subject) the semantics of

alice (did:example:123) controller bob (did:example456)

seems incorrect where as

alice (did:example:123) controller IoT device (did:example:789)

does not.

In the first example, alice doesn't control bob. She may represent him as a guardian or a custodian for his keys, but Bob still has sovereignty of himself which is where the semantics are miss modeled to the actual relationship of Bob and Alice. That's all I was trying to point out in the past post which was talking about how the DIDs represent the subjects and not the DID Document (which we agreed to in the past). So the controller property needs to either be moved to metadata about the DID Document (such that it's Alice controls Bob's DID Document) or the property should be renamed to accurately represent the semantics if it remains in the DID Document.

[OR13]

@kdenhartog the controller is most often seen as a property of the verificationMethod... the verificationMethod is a property of the did subject.

IMO, its fine as is, and changing it would be harmful at this time.

Here is a clearer example with a couple properties:

{
    "@context": [
      "https://w3id.org/did/v0.11"
    ],
    "id": "did:example:123",
    "publicKey": [
      {
        "type": "JsonWebKey2020",
        "id": "#key-0",
        "controller": "did:example:456",
        "publicKeyJwk": {
          "kty": "OKP",
          "crv": "Ed25519",
          "x": "uTMyN-jtj9BwsKsEIaX9dXnW5ZZ_dx_84ZQpgDTGeVA"
        }
      }
    ],
    "authentication": ["#key-0"],
    "assertionMethod": ["#key-0"],
    "capabilityDelegation": ["#key-0"],
    "capabilityInvocation": ["#key-0"],
    "keyAgreement": [
      {
        "id": "#key-2",
        "type": "X25519KeyAgreementKey2019",
        "controller": "did:example:789",
        "publicKeyBase58": "Be2n4pVHMedX2Evg16pYUUnJkdr3rUNFu9y61tConj5M"
      }
    ],
    "service": [{
        "id":"#vcs",
        "type": "VerifiableCredentialService",
        "serviceEndpoint": "https://example.com/vc/"
    }]
  }

not all the properties are about the did subject.... for example....

service[0].type is about service[0].id publicKey[0].type is about publicKey[0].id

if the did doc supported type it would be about the id...

https://w3c.github.io/did-core/#dfn-did-controllers

An entity that has the capability to make changes to a DID document. A DID may have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that one DID controller may be the DID subject.

<did:example:123#key-0> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <did:JsonWebKey2020> .
<did:example:123#key-0> <https://w3id.org/security#controller> <did:example:456> .
<did:example:123#key-2> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <did:X25519KeyAgreementKey2019> .
<did:example:123#key-2> <https://w3id.org/security#controller> <did:example:789> .
<did:example:123#key-2> <https://w3id.org/security#publicKeyBase58> "Be2n4pVHMedX2Evg16pYUUnJkdr3rUNFu9y61tConj5M" .
<did:example:123#vcs> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <did:VerifiableCredentialService> .
<did:example:123#vcs> <https://w3id.org/did#serviceEndpoint> <https://example.com/vc/> .
<did:example:123> <https://w3id.org/did#service> <did:example:123#vcs> .
<did:example:123> <https://w3id.org/security#assertionMethod> <did:example:123#key-0> .
<did:example:123> <https://w3id.org/security#authenticationMethod> <did:example:123#key-0> .
<did:example:123> <https://w3id.org/security#capabilityDelegationMethod> <did:example:123#key-0> .
<did:example:123> <https://w3id.org/security#capabilityInvocationMethod> <did:example:123#key-0> .
<did:example:123> <https://w3id.org/security#keyAgreementMethod> <did:example:123#key-2> .
<did:example:123> <https://w3id.org/security#publicKey> <did:example:123#key-0> .

Here we can see that controller is actually only used as a predicate related to verificationMethods...

Of course, this interpretation assumes we are being honest about RDF being the abstract data model.

See https://github.com/w3c/did-core/issues/439

[kdenhartog]

IMO, its fine as is, and changing it would be harmful at this time.

Taking into account our conversation about implementations that are trying to firm things up I tend to agree that changing it at this point would likely be too late. Especially since this discussion really only popped up past feature freeze which makes it harder to defend without objection.

With that in mind, I still think it's fair to say that the base controller property isn't accurate semantics and which is the property that I understood that we were discussing above. At this point, I think we could agree the semantics around that property is less than ideal, but given the effect it would have on implementations it's not worth changing (deprecation I could buy into) and we should remain operating under the assumption that the DID represents the DID subject and not the DID Document even though this property exists.

Does that still seem contreversial to you @OR13 ?

[OR13]

The base controller property has always confused me... I have not seen any real examples of it....

It appears to actually be sorta like alsoKnownAs... where:

alice controller bob where alice and bob are both dids.... but this is just an assertion from alice, it may not be true....

[msporny]

This discussion needs to result in a concrete PR before we go into CR. If we don't see a PR before we go into CR, this issue will be closed or deferred until the next version of the specification.

[talltree]

@msporny I was working on that PR this weekend but then was informed by the Chairs that I needed to lead a 90 minute section on Privacy in the first day of the virtual F2F tomorrow, so I had to prioritize preparing content for that first. I plan to submit the PR later this week.

[TallTed]

@talltree - Just checking on status of this (draft) PR...

[msporny]

This issue will be closed once PR #460 is merged.

[msporny]

PR #460 was merged a while ago, closing.