Re: Ideas about DID explanation

Perhaps think about the use case of a professional civil engineer
certifying that a bridge was designed correctly. Those signatures need to
survive at least 50+ years in case of bridge failure.

So the use case is very real and probably less rare than we might think.

Notarius.com offers a old-school (non-DID) service that deals with
long-lived signing keys - that's where I learned of this use case

*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 12:18 PM Kim Hamilton Duffy <kim@learningmachine.com>
wrote:

> 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
>