W3C home > Mailing lists > Public > public-credentials@w3.org > December 2018

Re: Ideas about DID explanation

From: Andrew Hughes <andrewhughes3000@gmail.com>
Date: Wed, 5 Dec 2018 08:11:54 -0800
Message-ID: <CAGJp9UZVfk6r0_1SCHmfgCNk3ue4iSxEGCKkNVCWQr36ijsA5g@mail.gmail.com>
To: daniel.hardman@evernym.com
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Well, the spec text says:

> (section 3.1) The term DID refers only to the identifier conforming to the
> did rule in the ABNF below...
>

(section 4) If a DID is the index key in a key-value pair, then the DID
> Document is the value to which the index key points. The combination of a
> DID and its associated DID Document forms the root record for a
> decentralized identifier.
>

 And the key paragraph might be:

> (section 3) A DID is similar to a UUID except: (a) like a URL, it can be
> resolved or dereferenced to a standard resource describing the entity (a
> DID Document—see Section 4. DID Documents ), and (b) unlike a URL, the DID
> Document typically contains cryptographic material that enables
> authentication of an entity associated with the DID.
>

Paraphrasing: "A DID is an identifier for an entity. A DID Document
describes that specific entity. The entity is known as the DID Subject"

Having typed all that, i'm unsure it if should go into the explainer text -
because it is stated clearly in the spec text and is quite detailed and
intricate.

However:  'includes' is incorrect according to the spec text. 'Associated'
is much more correct.
andrew.







*Andrew Hughes *CISM CISSP
*In Turn Information Management Consulting*

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road, Victoria, BC V8P 2H8
AndrewHughes3000@gmail.com
*https://www.linkedin.com/in/andrew-hughes-682058a
<https://www.linkedin.com/in/andrew-hughes-682058a>*
*Digital Identity | International Standards | Information Security *


On Tue, Dec 4, 2018 at 9:59 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> 5) includes the associated DID Document, which may contain material used
>>>> to authenticate the DID, the DID Document, and the DID 'owner/controller'
>>>>
>>>
>>> I have run into this sort of verbiage before, that a DID "includes" a
>>> DID Document. I think the phrase "is associated with" or "may be associated
>>> with" is more accurate. A DID that has been created but not yet written to
>>> anywhere that associates it with a DID Document is still a DID, is it not?
>>>
>>
>> <<<ACH: A DID without a DID Document cannot be authenticated, so might
>> not be too useful :) 'associated' is from the spec text.
>>
>
> Yes, I get that a DID without a DID Doc is not very useful. But we still
> can't say that a DID "*includes* the associated DID Document." This is
> conflating an identifier with the thing it identifies. Does a domain name
> "include the associated web server host name" by definition, or can it be
> bound to a hostname (registered in DNS) after the domain name exists in
> unregistered form? Likewise, can I create a DID and begin using it as an
> identifier in my own records, then decide later which endpoint and keys I
> want to use for that DID when I'm ready to share it? If so, what is the
> identifier called before it's associated? Surely it's called a DID, right?
> Or does it only become a DID when the association is completed, and before
> that it's a "potential DID"? What happens for a DID that's not stored on an
> immutable ledger, but in a mutable database, such that its registration can
> be deleted--does it cease to become a DID at that point?
>
> I know this is splitting hairs, but I have heard this same semantic
> shorthand several times, and it is making me uneasy. I think it leads to
> assumptions about temporal coupling and about the binding between a DID and
> crypto (a single entity must both create the identifier and bind it to
> keys+register it in the same event) that are not strictly required by the
> spec, and that may be undesirable in some cases.
>
Received on Wednesday, 5 December 2018 16:12:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 December 2018 16:12:31 UTC