Re: Ideas about DID explanation

I agree with Kim, this is TBD. Personally I believe all DID methods must
be able to return the latest DID document, but not all DID methods must
necessarily support keeping track of previous versions.

This is a topic that should be covered by the future did-resolution
<https://w3c-ccg.github.io/did-resolution/> specification.

I also had a section on this subject in the last RWoT topic paper:
https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/did-resolution-topics.md#did-document-versioning

Markus

On 12/8/18 8:48 PM, Kim Hamilton Duffy 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 <mailto: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 <mailto:AndrewHughes3000@gmail.com> 
>     _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 <mailto: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
>         <mailto: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 <tel:(650)%20209-7542>
>             m +1 250.888.9474 <tel:(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
>             <mailto:AndrewHughes3000@gmail.com> 
>             _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
>             <mailto: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 <mailto:kim@learningmachine.com>
>
> -- 
> Kim Hamilton Duffy
> CTO & Principal Architect Learning Machine
> Co-chair W3C Credentials Community Group
>
> kim@learningmachine.com <mailto:kim@learningmachine.com>
>