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

Re: Ideas about DID explanation

From: Kim Hamilton Duffy <kim@learningmachine.com>
Date: Sat, 8 Dec 2018 10:12:28 -0800
Message-ID: <CAB=TY87t-9HgvaWgAzzwxKHdA_zJb5v7bT+UKUGD8ems7kDsyQ@mail.gmail.com>
To: Andrew Hughes <andrewhughes3000@gmail.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>, daniel.hardman@evernym.com
This list is useful and I’d like to keep iterating on it. c and d are the
ones I'm stuck on.

> c) Authentication mechanisms, keying material, service endpoints, etc.
specified in the DID Document can be managed without requiring the DID
value to change.
> d) The ability to manage keying material without disturbing the DID value
enables key rotation and key recovery mechanisms

“Can be managed without requiring the DID value to change” may technically
be correct (i.e apply for some DID methods). For BTCR v0.1, we're requiring
an on-chain transaction for updates to the key material, resulting in a new
DID (again, this is specific to BTCR). These are linked through the
transaction chain, so you can get from one to the other but the DID "value"
(which I'm assuming to mean the DID itself) does change.

For Blockcerts use cases, it's critical to be able to see the state of the
DID Document (and related key material) at a given point in time. And for
BTCR v0.1, the tx is the source of the timestamp.

But this is all through a BTCR lens, and these
specific design/implementation choices may be uncommon. I'm curious to hear
how c and d relate to other DID methods.

On Wed, Dec 5, 2018 at 8:13 AM Andrew Hughes <andrewhughes3000@gmail.com>

> 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 <(650)%20209-7542>
> m +1 250.888.9474 <(250)%20888-9474>
> 1249 Palmer Road, Victoria, BC V8P 2H8
> <https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g>
> 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.
> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group

Received on Saturday, 8 December 2018 18:13:03 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 8 December 2018 18:13:04 UTC