Distinction between entity to which a DID pertains and entity that can weild the private verification key

[RieksJ]

DID Spec working draft 3 (17 Oct 2016), section 5.4, says "Proof of Ownership is the mechanism by which an identity owner can cryptographically prove ownership of a DID." This implies that the owner can weild the corresponding private verification key. However, this contradicts the description of "Identity owner" in section 2, where the owner is taken to be the entity to which the identity pertains, and examples are given of situations where this entity is not able or permitted to weild the private verification key.

I suggest to make a very clear distinction between the entity to which the identity pertains (currently called the owner) and the entity that is capable to weild the private verification key, and explicitly specify the case where they are the same.

One way to do this is to add a keyword to the verification key section, e.g. 'did_controller', that identifies the entity that is capable of weilding the private verification key. Values may be either a DID or 'self'.

In order to prevent further confusion about the often unclear term 'owner', I suggest to replace this term with something else, e.g. 'entity_id', or 'entity'.

[RieksJ]

Here is another argument.

In the real world, I not only can create an identity for me (i.e. a thought model of how I like to see myself), but I can also create an identity for you (i.e. a thought model of how I like to see you). The latter may not coincide with the way you like to think about yourself (i.e. your identity for you). Conversely, you can create an identity for me (e.g., you may like to see me as this stubborn Dutchman), which may not coincide with the way I see myself.

In the real world, people and organizations have mental models (ontologies) about what it is they perceive in the world. The identity of something they perceive in the world consists of whatever they perceive to be true about that entity: such (perceived) truths are attributed to this entity, and that is what makes up the identity of that entity within that mental model.

To be truly useful, I think DIDs should allow for the construction of such mental models. As the 'genesis claim' for an entity, a DID simply stipulates that the entity exists. This statement that some entity exists should be attributable to the mental model of which it is part. This can be done by saying that

• the DID/identity is controlled by one entity (person or organization) and
• the DID/identity is about a single entity (person, organization, or thing), and
• the controlling entity defines the semantic scope within which the identity has a well-defined meaning (i.e. the DID/identity represents an entity that exists in the mental model of its owner).

So, in order to allow for this, strict separation between the controlling entity and the identified entity is required.

[talltree]

ReiksJ, now that the spec has moved to the W3C Credentials Community Group (see https://opencreds.github.io/did-spec/), we are revisiting the names for all of the DID blocks.

With regard to the separation between the controlling entity and the identified entity that you suggest, I believe that DID architecture accomplishes this. To illustrate, let's take two entities, A and B, who want to form a relationship. Entity A creates a DID (based on a key pair generated by Entity A) and shares it with Entity B as a context-specific identifier for Entity A. While Entity A controls the private key for this DID, so Entity A can authenticate to Entity B using this DID, once Entity A shares this DID with Entity B, Entity B controls the "mental model" of the identity it builds for Entity A.

To be more specific, Entity B, if it is an issuer of verifiable claims, Entity B can decide what verifiable claims it will or will not issue to the DID to describe Entity A.

In other words, control of the private keys for a DID (and the associated DDO) is not the same thing as control over the identity that will be associated with that DID by the entity with whom that DID is shared. The entity identified by the DID controls the ability to authenticate to that DID, but the entity with who the DID is shared controls the ability to build a contextual identity for that DID. I believe that is what you are asking for.

To the extent that the verifiable claims from Entity B are shared back with Entity A, Entity A can now reshare them with Entity C to prove some aspects of Entity A's identity with respect to Entity B. This is how we can achieve an interoperable, contextual, privacy-respecting identity ecosystem in which any entity can issue verifiable claims about any other entity, and all entities can make their own contextual trust decisions.

[RieksJ]

@talltree, this seems to be sort of in line with our thoughts here.

I have a remark and two questions:

• the link https://opencreds.github.io/did-spec/ doesn't work;
• is there already some concrete work done on verifiable claims, e.g. specifying what a vc looks like? If so, I couldn't find it and would really appreciate to have a look.
• what if A would need to assert to C something about an entity that is not able to genarate/weild a private key?

[talltree]

@RieksJ, I am surprised that the link https://opencreds.github.io/did-spec/ does not work—it's maintained by contributors to the W3C Credentials Community Group, so I suspect it's just a temporary issue.

RE verifiable claims, yes, a great deal of work has been done. The latest reference I can provide is https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/ . The work is ongoing at the W3C Verifiable Claims Working Group: https://www.w3.org/2017/vc/

RE your third question, DIDs may be assigned to entities that are not able to wield private keys. In that case you have what in the spec we currently call a guardian relationship. That's a deep topic and I need to head to bed, but happy to discuss further if you are interested.

[msporny]

the link https://opencreds.github.io/did-spec/ doesn't work;

I just moved the spec yesterday and haven't had a chance to update the links. The latest draft is here:

https://w3c-ccg.github.io/did-spec/