Re: Ideas about DID explanation

a scenario that is close to our hearts today is a DID authorizing access to
a claim (attribute) with a signed stipulation (Mary/Kantara would call it a
user submitted term). If the user makes a claim under GDPR the data
controller will need to prove that the user authorized release of the
attribute. If the DID cannot be resolved at that later date, how is the
case to be resolved?
Peace ..tom


On Sat, Dec 8, 2018 at 12:21 PM Andrew Hughes <andrewhughes3000@gmail.com>
wrote:

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