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

Re: Ideas about DID explanation

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sun, 9 Dec 2018 18:18:56 +0100
To: =Drummond Reed <drummond.reed@evernym.com>, Stephen Curran <swcurran@cloudcompass.ca>
Cc: Christopher Allen <ChristopherA@lifewithalacrity.com>, Kim Hamilton Duffy <kim@learningmachine.com>, Andrew Hughes <andrewhughes3000@gmail.com>, Credentials Community Group <public-credentials@w3.org>, Daniel Hardman <daniel.hardman@evernym.com>
Message-ID: <f0ed0303-95b3-331e-6a42-0a6aff97dc4f@gmail.com>
On 2018-12-09 13:53, =Drummond Reed 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.

That's undeniable.

The problem I see is that this mapping involves a process as well which also have to be *repeated* for every party the user interacts with.


> 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 is true that this has happened but why would anybody use such a system today?
Internal violations (like looking into someone's file you are not supposed to do) will still be possible no matter what scheme you use.

The Canadians are apparently betting on an even more sophisticated scheme:
https://youtu.be/nyqhytBYQCc

Anders

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 <mailto: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 <http://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 <tel:250-857-1096>
>     W // https://www.cloudcompass.ca
>     Twitter <https://twitter.com/scurranC3I>
> 
>     __
>     On Dec 9 2018, at 9:03 am, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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
> 
Received on Sunday, 9 December 2018 17:19:24 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 December 2018 17:19:25 UTC