- 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