- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Tue, 16 Apr 2019 09:57:04 -0700
- To: Avesta Hojjati <avesta.hojjati@digicert.com>
- Cc: Adrian Gropper <agropper@healthurl.com>, Luca Boldrin <luca.boldrin@infocert.it>, "=Drummond Reed" <drummond.reed@evernym.com>, Credentials Community Group <public-credentials@w3.org>, David Chadwick <D.W.Chadwick@kent.ac.uk>
- Message-ID: <CAAjunnZa2tRRn+ZkQv_s=d7PAzd59nOO3tTw8qS6xgsez+iP_A@mail.gmail.com>
+1 to the importance of 1.b. As Avesta points out, decentralized identity requires decentralized key management, i.e., private keys in the hands of DID controllers. These wallets become a new attack target. In centralized systems, key stores have massive security protections—like what a bank provides when people put their money in a central bank vault. In decentralized identity, the attack surface is more like having to go to each person's house and break into their personal safe. But if breaking into that personal safe is trivial, then that could indeed happen at scale. So establishing strong security for decentralized wallets is important. Equally important are the usability and wallet recovery challenges—again factors that are very different from centralized key management systems. For example, options for key recovery were covered in detail in the new V4 version of the DKMS Design and Architecture document <http://bit.ly/dkms-v4> (published in the Hyperledger Indy github repo) that Evernym completed under a contract with the U.S. Department of Homeland Security. On Tue, Apr 16, 2019 at 9:10 AM Avesta Hojjati <avesta.hojjati@digicert.com> wrote: > 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: > > > > 1. Trust on the infrastructure, which may be further split into > > > 1. Trust on some underlying registry providing a common infrastructure > - This is the new element introduced by permissioned/unpermissioned > ledgers. (DID method) > 2. trust on the sw dealing with personal information (wallet, > agent) - This is similar to the role of browsers > > > 1. trust on the information, which may be further split into > > > 1. trust on the identity of VC issuers (is universityX really > universityX?)– This is the traditional role for CAs > 2. 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: > > 1. The DID method > 2. 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/ >
Received on Tuesday, 16 April 2019 16:57:42 UTC