Re: Ideas about DID explanation

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
>