Support "controller" at the top-level of a DID Document

[dlongley]

While DID methods may already add a "controller" property (aka "owner") at the top-level of a DID Document, I think we should consider explicitly talking about this pattern in the DID spec as it helps with interoperability.

This is very similar to an early proposal to have a "guardian" property for DID Documents that do not contain any key material to enable updates or authentication, etc. Adding an optional "controller" property at the top-level would serve this same purpose, but I think the semantics are clearer and that it works better with Linked Data Proofs and Object Capabilities.

As an example of usage where an Object Capability model is being used to update DID Documents, a DID Document can be self-invoked using one of its "capabilityInvocation" keys to update itself. If a DID Document is not intended to represent an actor-like entity (but rather any other kind of inert "thing") then it will not have its own "capabilityInvocation" keys (nor can it ever "authenticate", so it has no keys there either). However, updating such a DID Document is still desirable. This can be enabled by adding a "controller" property to the DID Document with a value of some other DID that can perform capability invocation to update itself or entities it "controls". This also makes it more clear that representing any sort of "non-actor" entities on DID networks is a real thing.

cc: @talltree

[jandrieu]

I think this would be a mistake. The controller is "whoever can produce the proof". Adding the notion of another identifier creates a dichotomy that is not easily resolved.

Perhaps we can address your use case with a proof method that relies on proof of control of a specified DID.

IMO, we shouldn't be relying on the semantics of any properties outside the proof section to prove control of a DID.

[dlongley]

The controller is "whoever can produce the proof".

That's how that is used here. The "controller" specifies the DID of the entity that can produce the proof to update the DID Document.

Perhaps we can address your use case with a proof method that relies on proof of control of a specified DID.

That's what this does. The DID is specified via the "controller" property and one must produce a proof demonstrating control of that DID in order to update the "controlled" DID Document.

IMO, we shouldn't be relying on the semantics of any properties outside the proof section to prove control of a DID.

I don't understand this part -- that's already what we do with every other proof purpose. The property "authentication" (outside of the proof section and in the top-level of the DID Document), for example, maps to verification methods (public keys) that can be used to verify a proof created for the purpose of authenticating as an entity identified by a DID.

[jandrieu]

The proposal, as I understood it was to put the property at the top-level. In my conversations with Dan at the December workshop about conformance in light of "verify" versus "valid", it made sense to come up with language like "The entirety of the credential MUST satisfy the proof mechanism(s) specified in the proof property."

I'd like to continue that pattern with DIDs, so we could say "The entirety of the DID document MUST satisfy the proof mechanism(s) specified in the proof property."

Of course, you could have a proof mechanism that interprets properties outside the proof section semantically instead of as a data blob, but I prefer the separation and encapsulation of being able to treat the entirety of the document as a blob input to an algorithm defined by the proof type with any necessary parameters specified in the proof section.

[dlongley]

I'd like to continue that pattern with DIDs, so we could say "The entirety of the DID document MUST satisfy the proof mechanism(s) specified in the proof property."

I'm not sure which "proof" property you're referring to with respect to DID Documents. I think most DID methods do not directly attach proofs to DID Documents. It may help to take this to a more high-bandwidth conversation medium to work through any miscommunication.

[jandrieu]

4.9 Proof (Optional)
A proof on a DID Document is cryptographic proof of the integrity of the DID Document according to either:

The entity as defined in section 4.6 Service Endpoints , or if not present:
The delegate as defined in section 4.3.
This proof is NOT proof of the binding between a DID and a DID Document. See Section 7.2 Binding of Identity . The rules for a proof are:

A DID Document MAY have exactly one property representing a proof.
The key for this property MUST be proof.
The value of this key MUST be a valid JSON-LD proof as defined by Linked Data Proofs.
Example:

EXAMPLE 11: A signature-based proof
{
"proof": {
"type": "LinkedDataSignature2015",
"created": "2016-02-08T16:02:20Z",
"creator": "did:example:8uQhQMGzWxR8vw5P3UWH1ja#keys-1",
"signatureValue": "QNB13Y7Q9...1tzjn4w=="
}
}

[jandrieu]

That said, the language about binding is confusing and would need to be changed you support your delegation approach.

[peacekeeper]

@dlongley can this be closed now that #242 has been merged?

[dlongley]

@peacekeeper, yes, closing.