- From: Adam Lake <alake@digitalbazaar.com>
- Date: Tue, 4 Dec 2018 20:41:50 -0500
- To: public-credentials@w3.org
- Message-ID: <b3d2a7a8-998c-c1fe-ed17-559e34b44bfe@digitalbazaar.com>
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 > <mailto: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 > > AndrewHughes3000@gmail.com <mailto:AndrewHughes3000@gmail.com> > <mailto: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 > AndrewHughes3000@gmail.com <mailto: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
Received on Wednesday, 5 December 2018 01:42:24 UTC