Re: Ideas about DID explanation

Yep - I think that being able to explain what a DID is and its special
properties is one task. Being able to describe scenarios where these
special properties allow new possibilities (and why existing identified
won't give the same benefits) is also important.

But I think we as the CCG tend to talk about the latter and we've been
given feedback that our audience wants more of the former.

For example, I only just came to understand a few weeks ago that having the
authentication parts in the DID document is how long term key management is
possible. This is what makes a DID more than just a complex private key.
And that is how the claim of long term persistence is made possible.

On Tue, Dec 4, 2018 at 5:43 PM Adam Lake <alake@digitalbazaar.com> wrote:

> I appreciate the conversation going on here. It's very important that we
> are able to concisely communicate the value of DID's and associated
> technologies.
>
> Separating what DID's are from what they enable makes sense to me. DID's
> "are" persistent Web identifiers that are difficult to take away from the
> entity that can authenticate with it. DID's "enable" data portability and
> selective disclosure but they are not guaranteed by the nature of DIDness.
> :)
>
> For me, DID's enabling data portability is one of the more compelling
> features. Whether that data be Verifiable Credentials, shared documents on
> a personal cloud, app data, or ones social connections, the fact that you
> can take your data wherever you choose and use it how you see fitse
> represents a type of civil liberty we should expect in the digital age.
>
> If this model truly underpins Web 3.0 it will be a positive sea change for
> the Web and global society. It really is a new paradigm with deep
> implications. I know I am preaching to the choir here but a little extra
> positivity never hurt anyone! It's a pleasure to be part of this community.
>
> Adam
> On 12/4/2018 7:28 PM, Andrew Hughes wrote:
>
> Fair enough...
>
> Although, the important thing about 1) is not self-insurance but rather
> that any entity can accept and resolve any DID. Also, data portability and
> selective disclosure are not charatacteristics of DIDs but perhaps of other
> mechanisms that might use DIDs as identifiers.
>
> The lists intend to express 1) what a DID **is** and a) some interesting
> characteristis about how DIDs address issues in other systems and i) random
> additional stuff that is probably extra. There isn't much about how one
> could exploit these properties in an implementation.
>
> On Tue, Dec 4, 2018 at 4:09 PM Steven Rowat <steven_rowat@sunshine.net>
> wrote:
>
>> On 2018-12-04 1:18 PM, Andrew Hughes wrote:
>>
>> >> What do you think? Is this close?
>>
>> I feel that it's close, especially taking them all together.
>>
>> Reading them all inspired me to to take another stab at a version for
>> less technical people, as just four points:
>>
>> 1-- An identifier that can be self-issued;
>> 2-- and allows selective disclosure;
>> 3-- and data portability;
>> 4-- and persistence.
>>
>> To my reading, your lists cover three of these explicitly (1, 2 and 4)
>> and perhaps #3, data portability, by implication, though I'm not
>> certain of that due to my unfamiliarity with some of the terms.
>>
>> My only concern is that your lists seem to split them; selective
>> disclosure, and possibly data portability, only appear in the second
>> list. Thus if only one list was read by a certain targeted audience
>> they might develop a fragmentary understanding of the basic
>> advantages....?
>>
>> Steven
>>
>>
>> > Looking back on my prior notes about how to explain decentralized
>> > identifiers, and why they are significantly different than existing
>> > identifier schemes, I've come up with a list. This is what I noted
>> > while you were all discussing the topic on the credentials community
>> > group calls - I just collected it all up.
>> >
>> > Please let me know if these points are correct and add value - if yes,
>> > then I suggest that we should include similar bullets in the DID
>> > Explainer.
>> >
>> > A Decentralized Identifier:
>> > 1) is a Uniform Resource Identifier (an identifier that identifies an
>> > abstract or physical resource)
>> > 2) is a Uniform Resource Name (a URI that is intended to persistently
>> > identify a resource, in this case the Subject)
>> > 3) may be a self-issued identifier
>> > 4) cannot be 'cancelled' by an authority
>> > 5) includes the associated DID Document, which may contain material
>> > used to authenticate the DID, the DID Document, and the DID
>> > 'owner/controller'
>> >
>> > a) DID authentication may use cryptographic proofs to demonstrate
>> > which entity is the 'owner/controller'.
>> > b) When cryptographic proofs for DID authentication are used, this
>> > enables special properties associated with zero knowledge proofs such
>> > as selective disclosure, <<what is this list?>>
>> > 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
>> > e) The registry of DID Methods accepts all valid DID Method Schemes,
>> > therefore the DID namespace may be extended to cover existing and
>> > previously-unknown identifier schemes or technologies.
>> >
>> > A DID also
>> > i) may be a Uniform Resource Locator if it is resolved to locate a
>> > resource on the Web.
>> > ii) can be directly used, referenced and resolved in any DLT by
>> > writing a new DID method
>> >
>> > Each of the lists kinda speaks to a slightly different audience to
>> > address their concerns and questions. The implications of each bullet
>> > could also be expanded if needed (e.g WHY is it significant that a DID
>> > cannot be cancelled by an authority?, etc)
>> >
>> > What do you think? Is this close?
>> > It assumes that the reader is familiar with namespace characteristics,
>> > namespace management, key management, resolvers. And generally,
>> > issues/strengths with them. Which probably describes our current
>> > target audience. If the 'cryptographic' bullets are enhanced then it
>> > can also speak to 'crypto-people'.
>> >
>> > Thanks to Markus for helping refine this but, of course, any
>> > misunderstandings or errors are all mine.
>> > 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 *
>> >
>>
> --
> 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
> Digital Identity | International Standards | Information Security
>
>
> --
> Adam Lake
> Director, Business Development
> Digital Bazaar
> Veres.io
> 540-285-0083
>
> --
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
Digital Identity | International Standards | Information Security