- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Tue, 17 Sep 2019 11:33:22 -0400
- To: daniel.hardman@evernym.com, Joe Andrieu <joe@legreq.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
An issue has been started that is related to this in the DID WG repo: https://github.com/w3c/did-spec/issues/2 On 9/16/19 9:20 PM, Daniel Hardman wrote: > I'm not aware of the term "controller of the DID Document" -- and I > didn't use that phrase. There *is*, however, such a thing as a > "controller of a DID"--a phrase I did use. The terminology section gives > a relatively circular definition: "DID Controller: The entity, or a > group of entities, in control of a DID and/or DID Document" -- but > section 5.4 expands on it: > > > 5.4 Authentication > > Authentication is the mechanism by which the controller(s) of a DID > can cryptographically prove that they are associated with that DID. > See Section § 9.3 Binding of Identity > <https://w3c-ccg.github.io/did-spec/#binding-of-identity>. Note that > Authentication is separate from Authorization because the > controllers may wish to enable others to update their DID Document > (for example, to assist with key recovery as discussed in > Section § 9.8 Key Revocation and Recovery > <https://w3c-ccg.github.io/did-spec/#key-revocation-and-recovery>) > without enabling them to prove control (and thus be able to > impersonate the controllers). > > Note how this equates proving control with impersonation and > authentication, and how it contrasts this control with authorization to > edit. > > I understand this to mean that authorization to edit a doc (which is NOT > control) goes in the authorizationsection (or in other undefined > locations) -- but authentication (which IS control) goes in the > authenticationsection. A controller is a person who can sign or > otherwise authenticate with the DID. Control of a DID has nothing to do > with editing the doc. What is being controlled is DID /usage/. > > I imagine this could be interpreted differently. But if so, how does > one prove control *without* putting a key in the authenticationsection? > In other words, where in the DID doc could I find controllers, if not > there? And where in the spec, not in tribal knowledge, is this clarified? > > --Daniel > > > > > On Mon, Sep 16, 2019 at 5:45 PM Joe Andrieu <joe@legreq.com > <mailto:joe@legreq.com>> wrote: > > __ > Daniel, > > The keys in the authentication block are *by design* not necessarily > controllers of the DID Document. > > The whole point of the authentication property is to enable the use > of keys for authentication which *in fact* cannot change the DID > document, enabling, for example, cold-storage and infrequent use of > controlling keys while day-to-day transactions might use keys stored > "hot". It would also enable better group identifiers where control > of the group is restricted, but each member of the group is able to > authenticate as a legitimate claimant as the DID subject. > > I can't comment on the rest of Sethi's question, but I was able to > run this by several folks here at the TPAC meeting, including Markus > and they shared my understanding. > > -j > > On Tue, Sep 17, 2019, at 12:56 AM, Daniel Hardman wrote: >> Sethi: >> >> All keys listed in the authentication section of a DID doc are >> controllers of the DID for that doc. So if a DID doc is about >> did:example:12345, and if the authentication section of its DID >> doc lists 5 keys, then did:example:12345 has 5 controlling keys. >> >> Where this may confuse people is that the keys listed in that >> authentication block *could* belong to other DIDs. For example, >> the DID for Acme Corp could list the keys of 5 executives that >> each are capable of controlling the corporate DID. In such a case, >> you might see something like this, in the DID Doc for Acme Corp's >> did:example:12345 DID: >> >> authentication: [ >> {"id": "did:abc:98765#key2", ....} // the key for exec #1 -- >> listed as key2 in that exec's DID doc >> {"id": "did:def:65423#key1", ...} // the key for exec #2 -- >> listed as key1 in that exec's DID doc >> ...and 3 more keys for the other 3 execs... >> ] >> >> These 5 keys may or may not be controllers in their source >> context--the DID docs belonging to the execs. But they *are* >> controllers of the Acme DID, which is why they're listed in Acme's >> DID doc. >> >> Does that help? >> >> On Mon, Sep 16, 2019 at 5:36 AM sethi shivam >> <sethishivam27@gmail.com <mailto:sethishivam27@gmail.com>> wrote: >> >> Hi Team , >> >> I have a question . >> >> "authentication": >> >> { >> "id": "did:example:123456789abcdefghi#keys-2", >> "type": "Ed25519VerificationKey2018", >> "controller": "did:example:123456789abcdefghi", >> "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" >> } >> ] >> >> Here in authentication controller of >> >> "id": "did:example:123456789abcdefghi#keys-2", is >> "controller": "did:example:123456789abcdefghi", >> >> and public key of controller is >> "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" >> >> Am i right ? >> >> and >> >> now the value of key-2 is >> >> { "id": "did:example:123456789abcdefghi#keys-2", "type": >> "Ed25519VerificationKey2018", "controller": >> "did:example:pqrstuvwxyz0987654321", "publicKeyBase58": >> "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } >> >> >> which means "controller": "did:example:123456789abcdefghi" >> controls DID "id": "did:example:123456789abcdefghi#keys-2", >> >> and public key of "id": >> "did:example:123456789abcdefghi#keys-2", is >> >> { "id": "did:example:123456789abcdefghi#keys-2", "type": >> "Ed25519VerificationKey2018", "controller": >> "did:example:pqrstuvwxyz0987654321", "publicKeyBase58": >> "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" >> >> } >> >> now i am confused ,the public key mentioned under #key-2 is of controller or the DID >> >> and if the public key is of controller then do we need to add >> another attribute to mention the public key of actual owner? >> >> I am a bit confused .Please help >> >> Regards >> >> Sethi Shivam > > -- > Joe Andrieu, PMP > joe@legreq.com <mailto:joe@legreq.com> > LEGENDARY REQUIREMENTS > +1(805)705-8651 > Do what matters. > http://legreq.com > <http://www.legendaryrequirements.com> > > -- Dave Longley CTO Digital Bazaar, Inc.
Received on Tuesday, 17 September 2019 15:33:50 UTC