Re: Ideas about DID explanation

The ability to sign a prescription credential without having to update a
DLT depends on the signature remaining verifiable even after key rotation,
doesn't it?

Adrian

On Sat, Dec 8, 2018 at 4:00 PM Tom Jones <thomasclinganjones@gmail.com>
wrote:

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

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/