Re: Regarding DID Authentication

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 authorization section (or in other undefined
locations) -- but authentication (which IS control) goes in the
authentication section. 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 authentication section? 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> 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>
> 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
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>