Re: Ideas about DID explanation

Interesting. Does the DID method specify how to trace the history of the
DID forward as it changes (not just in the BTCR method)?

Say I interact with an EntityA in Year 0 and they register the DID I'm
using at that time. If in Year 2 I rotate the key material, thus resulting
in a new DID. If I return to EntityA in Year 3, which DID do I use to
authenticate myself? Do I keep the list of all my EntityA interactions so
that I can present the DID they should know me by (even though that DID had
its keys changed)? Or do I present the current instantiation of the DID
that they used to know me by, notifying them to remember to trace it back
through time? And then they can trace back through the on-chain
transactions to demonstrate that the new DID I present is in fact the
current version of the original DID they used to know me by?

Yes, I'm curious how each of the DID methods actually implement key
material changes etc.

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 Sat, Dec 8, 2018 at 10:12 AM Kim Hamilton Duffy <kim@learningmachine.com>
wrote:

> 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>
> wrote:
>
>> 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
>
> kim@learningmachine.com
>