Re: Materials from 2019-04-11 combined DID Spec and DID Resolution Spec meeting

In regards to 1.b there are number of differences between the browser and agent/wallet approach. This is especially important given the fact that the user (or a designated entity) will handle the private keys.  

 

-Avesta 

 

From: Adrian Gropper <agropper@healthurl.com>
Date: Tuesday, April 16, 2019 at 10:30 AM
To: Luca Boldrin <luca.boldrin@infocert.it>
Cc: =Drummond Reed <drummond.reed@evernym.com>, Avesta Hojjati <avesta.hojjati@digicert.com>, Credentials Community Group <public-credentials@w3.org>, David Chadwick <D.W.Chadwick@kent.ac.uk>
Subject: Re: Materials from 2019-04-11 combined DID Spec and DID Resolution Spec meeting

 

Does 1b really matter? How I come to present my license to the TSA inspector does not matter now.

 

Adrian

 

On Tue, Apr 16, 2019 at 2:09 AM Luca Boldrin <luca.boldrin@infocert.it> wrote:

In a recent discussion with Digicert on the role of CAs in this setting, we came to a fully overlapping view: 

 
Trust on the infrastructure, which may be further split into 
Trust on some underlying registry providing a common infrastructure - This is the new element introduced by permissioned/unpermissioned ledgers. (DID method)
trust on the sw dealing with personal information (wallet, agent) - This is similar to the role of browsers 
trust on the information, which may be further split into 
trust on the identity of VC issuers (is universityX really universityX?)– This is the traditional role for CAs
trust on the VC issuer himself (given that universityX is universityX, can I trust it?)– this is a personal choice, which may be supported by domain specific agreements. 
 

The playing field between is “mega VC issuers” and “small distributed VC issuers” is probably on 2.b. 

We believe that 2.a is functional to trust on small distributed issuers, since under some regulatory setting the certainty of the identity (2.a) supports the enforcement of liability, which is an essential component of trust. Mega VC issuers do not need that, they are well-known…

Best,

--luca

 

 

Da: =Drummond Reed <drummond.reed@evernym.com> 
Inviato: martedì 16 aprile 2019 02:28
A: David Chadwick <D.W.Chadwick@kent.ac.uk>
Cc: Credentials Community Group <public-credentials@w3.org>
Oggetto: Re: Materials from 2019-04-11 combined DID Spec and DID Resolution Spec meeting

 

David is correct that with decentralized identity and verifiable credentials, verifiers are making two levels of trust decisions:

The DID method
The VC issuer.
Trust in the DID method only matters insofar as the verifier believes that the DID & DID document is actually controlled by and authoritative for the VC issuer. The vast majority of the trust reliance is on the VC issuer.

 

To the extent that a large number of verifiers default to trusting Google and Facebook as "mega VC issuers", as David calls them, they indeed could end out with the majority of "trust market power". But since anyone can issue VCs—by design—it doesn't seem that's a problem we can solve with the technical specifications alone. As David says, that's a matter of many others who are source of trust in the economy today asserting themselves in decentralized identity infrastructure.

 

On Mon, Apr 15, 2019 at 3:03 PM David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:



On 15/04/2019 18:53, =Drummond Reed wrote:
> With DIDs and SSI, we are moving from an IDP model to a digital
> credential model.

whilst the above is hopefully true

> Now the root of trust is not an IDP, it is the network
> in which a DID is rooted

I dont believe the above is. Users of SSI will still need a trusted
issuer, one that the verifier trusts. And if verifiers decide to migrate
towards a mega issuer such as google, then google and facebook could
still corner the VC issuing market. Especially if today's existing
trusted issuers in the physical world don't get their act together and
start to issue VCs in the virtual world.

David

-- 

 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

DONATE: https://patientprivacyrights.org/donate-3/