Re: Ideas about DID explanation

I believe so.
Peace ..tom


On Sat, Dec 8, 2018 at 1:01 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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