W3C home > Mailing lists > Public > public-credentials@w3.org > December 2018

Re: Ideas about DID explanation

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>
Message-ID: <c1d7fe77-fc78-5bf5-6bcc-5b99e2fa32c0@sunshine.net>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 December 2018 00:09:42 UTC