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

Re: Ideas about DID explanation

From: Andrew Hughes <andrewhughes3000@gmail.com>
Date: Tue, 4 Dec 2018 16:28:53 -0800
Message-ID: <CAGJp9UbbGPt=cQF9gvZpt6B5Cm+YDXCD-zuZpBBUm-N8Qe1Sxg@mail.gmail.com>
To: Steven Rowat <steven_rowat@sunshine.net>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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
> > 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
https://www.linkedin.com/in/andrew-hughes-682058a
Digital Identity | International Standards | Information Security
Received on Wednesday, 5 December 2018 00:29:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 December 2018 00:29:27 UTC