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

Re: Ideas about DID explanation

From: =Drummond Reed <drummond.reed@evernym.com>
Date: Sun, 9 Dec 2018 15:41:04 +0000
Message-ID: <CAAjunnZcCeq-EXoLXcAcL9GmuJpGjdvWLP1X26pAt_0OPzEsJg@mail.gmail.com>
To: Andrew Hughes <andrewhughes3000@gmail.com>
Cc: Christopher Allen <ChristopherA@lifewithalacrity.com>, Credentials Community Group <public-credentials@w3.org>, Daniel Hardman <daniel.hardman@evernym.com>, Kim Hamilton Duffy <kim@learningmachine.com>, Stephen Curran <swcurran@cloudcompass.ca>, anders.rundgren.net@gmail.com
On Sun, Dec 9, 2018 at 3:16 PM Andrew Hughes <andrewhughes3000@gmail.com>

> Ok - now to translate into more recognizable language ;-)
> (And yes, I’m a supporter-nothing in this post is negative)
> If you said this to any Business system owner, they might be nervous...
> Drummond  - your middle paragraph might be a uniquely US-tainted statement
> because there is no prohibition on using Social Security Number as a naked
> unauthenticated identifier. To contrast, in Canada in the 80’s, faced with
> rampant misuse of our equivalent number, the federal government made it
> illegal to use the number as an identifier beyond it’s stated purpose
> related to taxation.

Andrew, thanks, I was not aware of that. Good move by the
Canadian government. I hope the U.S. follows suit.

> Also, in Europe, citizen identification numbers are not secret.



> A few statements that I have picked up along the way:
> Identifiers must not be secret
> The ability to assert an identifier (“possession”) does not equate to
> control over that identifier
> I think about the identifiers used on the Web today: typically email
> address. Clearly not secret and knowing the email address does not mean it
> is your email address. A weakness in the scheme is that people use the same
> identifier everywhere because they are humans.
> But look behind the implementation into the pattern and concept (this is
> the critical explanation part, by the way)
> *The service provider accepts whatever identifier that the person gives
> them*
> Then the service provider executes their chosen authentication strategy
> (local, federated, etc) to establish an authenticated identifier.
> This is directly what we are asking service providers to do: a) accept a
> DID as the identifier, and b) use the Authentication method of that DID to
> achieve the authenticated identifier.
> They already do a) if they operate a modern system. They should be
> sceptical and nervous about doing b)
> That’s the part we should focus on - the authenticated identifier, not the
> identifier.
> Why do we believe that the new authentication techniques are as strong or
> stronger than what they have today?

Because DID-based authentication uses public/private key crypto. It's the
same force driving FIDO adoption; just more generalized and portable.


> On Sun, Dec 9, 2018 at 4:53 AM =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>> To generalize on Stephen's (excellent) point, any system of record—not
>> just governments—can follow the same pattern: map their internal identifier
>> for a subject (citizen/customer/employee/contractor/partner/etc.) to
>> a pairwise pseudonymous DID supplied by the subject.
>> Now the subject can prove control over the DID to the system of record
>> *without* having to use/reuse the system of record's internal identifier
>> anywhere. Suddenly the ability for anyone to use an internal identifier as
>> proof of identity just goes away. It moves where it should: to the private
>> key(s) for a DID—and that DID shared with only the parties who need to know
>> that it.
>> Stronger security, stronger privacy, lifetime portability. What's not to
>> like about this picture? (Other than the key management, which we are
>> working on diligently).
>> On Sun, Dec 9, 2018 at 11:56 AM Stephen Curran <swcurran@cloudcompass.ca>
>> wrote:
>>> How a government system can get to using centrally issued IDs is exactly
>>> what we are trying to do in British Columbia with VON (https://vonx.io).
>>> We are building out the supply side of Verifiable Credentials of government
>>> IDs (public ones, initially) to create a demand from Organizations (run by
>>> Individuals) to be Holders and Provers of those Verifiable Credentials. Any
>>> jurisdiction can make use of the VON tools/techniques to participate in
>>> building that demand.
>>> Data breaches that have made someone knowing a tax-id irrelevant as to
>>> whether they are the subject of that ID has made the standalone use of
>>> those IDs pretty much useless - online or off. Requiring the presentation
>>> (proof) of a claim of that ID from a Verifiable Credential issued by an
>>> authorative source is of value, and is exactly what will motivate
>>> governments to move to this model. We believe this model will be a far
>>> cheaper and scalable vs. traditional IP/IAM systems.
>>> *Stephen Curran*
>>> Principal, Cloud Compass Computing, Inc.
>>> P // 250-857-1096
>>> W // https://www.cloudcompass.ca
>>> [image: Twitter] <https://twitter.com/scurranC3I>
>>> On Dec 9 2018, at 9:03 am, Anders Rundgren <
>>> anders.rundgren.net@gmail.com> wrote:
>>> Hi Guys,
>>> For me working in the other end of the identity conundrum [1] it would
>>> still be interesting knowing if there is (or could be) a "union" between
>>> these opposing universes.
>>> Although I'm personally heavy into innovation [2], I find that schemes
>>> that requires "total rewrite of everything" tend to go nowhere.
>>> Basic question: How could an existing government system using centrally
>>> issues tax numbers gradually adopt DIDs?
>>> thanx,
>>> Anders
>>> 1] https://1drv.ms/b/s!AmhUDQ0Od0GTgWnVtlfN9jTPx1LR
>>> 2] https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf
>>> --
> 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 Sunday, 9 December 2018 15:41:40 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 December 2018 15:41:41 UTC