- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Tue, 4 Dec 2018 16:10:06 -0800
- To: Andrew Hughes <andrewhughes3000@gmail.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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> > _https://www.linkedin.com/in/andrew-hughes-682058a_ > *Digital Identity | International Standards | Information Security * >
Received on Wednesday, 5 December 2018 00:09:41 UTC