Re: Ideas about DID explanation

I’m not sure if I understand the question, but for some longer-lived claims
it’s useful to be able to determine the keys associated with a DID at a
given point in time. I think I’m the only one that keeps harping on this,
so the need for this capability may be quite rare.
On Sat, Dec 8, 2018 at 12:00 PM Tom Jones <thomasclinganjones@gmail.com>
wrote:

> Statement 2 seems to imply that (in general) the DID cannot be used in any
> way in the signature of any sort of document as verification of that
> signature always requires a historical reference?
>
> Peace ..tom
>
>
> On Sat, Dec 8, 2018 at 11:49 AM Kim Hamilton Duffy <
> kim@learningmachine.com> wrote:
>
>> I recall in the context of universal resolver discussions the following:
>>
>> 1. DID methods must allow discovery of the latest version of the DID doc
>> (fairly sure there was no pushback on that)
>> 2. TBD whether all methods must (or even are able to) support
>> point-in-time historical lookups
>>
>> And I’m not sure if we’ve written these down anywhere (in github issues,
>> etc) or if this is tribal knowledge. I will set a reminder to investigate
>> if no one has the answer handy
>>
>> On Sat, Dec 8, 2018 at 10:20 AM Andrew Hughes <andrewhughes3000@gmail.com>
>> wrote:
>>
>>> 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
>>> <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 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
>>>>
>>> --
>> Kim Hamilton Duffy
>> CTO & Principal Architect Learning Machine
>> Co-chair W3C Credentials Community Group
>>
>> kim@learningmachine.com
>>
> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group

kim@learningmachine.com