- From: Bill Claxton, NextID Founder & Operations Director <williamc@nextid.com>
- Date: Wed, 24 Mar 2021 12:26:42 +0800
- To: public-credentials@w3.org
- Message-ID: <303132af-f6ec-faf7-729c-6ed184553fc7@nextid.com>
I have been following this discussion with interest. I disagree that (paraphrasing Michael) only the register is decentralised and (quoting Leonard) VC and DID are *NOT* decentralized. Here are some points of decentralisation which are inherent to VCs. - the issuer may delegate data processing and production to one or more entities - ownership privilege belongs to the identity owner and not the issuer (which 'breaks the silo') - identity owners have autonomy over what VCs they share and with whom they are shared - verification services can be created and operate independently of issuers - relying parties can verify a VC without reference to the issuer (and without being tracked) In brief - _VC production, usage and verification are all decentralised_ regardless of whether a blockchain anchor is used to assure immutability. I would add that VC storage is separate from a blockchain registry, and that storage can also be decentralised using IPFS or similar architectures. Regards, Bill Claxton (williamc@nextid.com <mailto:williamc@nextid.com>) LinkedIn, Facebook, Telegram, Slack, Skype, Twitter or Gmail: wmclaxton SG Voice, Text or Whatsapp: +65-9012-4327 US Voice, Text or Voicemail: +1-415-797-7348 On 3/24/2021 11:04 AM, Michael Herman (Trusted Digital Web) wrote: > > Here’s some simple but precise wording that may appeal to some folks: > > *Digital Identity* > > A Digital Identity aggregates: > > * A Digital Identifier, and > * Associated Digital Identity Data. > > *Decentralized Identity* > > A Decentralized Identity is a Digital Identity that is Verifiable. > > A Decentralized Identity is often persisted in a Verifiable Data Register. > > The only part that typically relates to /decentralized infrastructure/ > is the Verifiable Data Register. > > Best regards, > > Michael > > p.s. Here’s a copy of the big picture that visually relates all of the > above terms: > https://hyperonomy.com/2021/03/23/tdw-glossary-the-big-picture/ > <https://hyperonomy.com/2021/03/23/tdw-glossary-the-big-picture/> > > *From:*David Waite <dwaite@pingidentity.com> > *Sent:* March 23, 2021 7:50 PM > *To:* Jim St.Clair <jim.stclair@lumedic.io> > *Cc:* Leonard Rosenthol <lrosenth@adobe.com>; Drummond Reed > <drummond.reed@evernym.com>; Michael Herman (Trusted Digital Web) > <mwherman@parallelspace.net>; sankarshan <sankarshan@dhiway.com>; W3C > Credentials CG (Public List) <public-credentials@w3.org> > *Subject:* Re: The "self-sovereign" problem (was: The SSI protocols > challenge) > > On Tue, Mar 23, 2021 at 2:43 PM Jim St.Clair <jim.stclair@lumedic.io > <mailto:jim.stclair@lumedic.io>> wrote: > > “VC and DID are **NOT** decentralized.” > > * Isn’t the first word in DID decentralized? > > The decentralization in DIDs conflates whether it means it represents > infrastructural decentralization in terms of the impact on reliability > of a single point of failure (which just about every internet > protocol has support for), or decentralization of authority - saying > that the infrastructure is not run by a single organization but is > rather a group of parties under a governance model. > > In any case, there is nothing about DID itself that makes it more > decentralized than your average other URI scheme - it is the DID > methods which refer to systems which may be _depoyed_ in such a manner > to have infrastructural and authority decentralization. For all I > know, an arbitrary DID method might resolve through a PHP script > running on a $35/yr hosting account. > > The subject may choose to use a DID method that meets their > requirements here (likely that 99.9% will only do so under guidance, > the DID rubric document has way more text on this topic). Likewise > issuers, verifiers and wallets may all choose to reject use of that > DID method - supporting a new DID method has an unquantified security > and reliability cost. > > In terms of deploying "decentralized" technology, there is nothing > about VCs or DIDs which mandates these concepts of decentralization, > or even requires a deployment to _allow_ for decentralization. As an > example, my employer or bank may restrict the DID subject to one they > control so that I am unable to choose unaudited forms of validation. > > Likewise, there are no DRM-like technical measures to extend a > person's self-sovereignty outside of their own choice of interactions > - a party may correlate the user by every piece of information they > can get ahold of, defeat attempts to use distinct personas, and so on. > The inverse is, there are no technical reasons you could not use > existing protocols like OpenID Connect to implement a decentralized > system that respects user's consent and control - Dick Hardt is > attempting to do that with https://signin.org <https://signin.org> as > an example. The technology just may have limitations that you would > not have with a newer protocol choice (as is always the case). > > So basically: > > - DIDs and VCs do not mandate organizational decentralization or > infrastructural decentralization, and implying so both sets > unrealistic expectations and is negatively impacting adoption > > - Self-sovereignty is a societal/legal initiative and construct, not a > technical one - but there are obviously aspects which make a > particular technology a better fit for self-sovereignty. > > -DW > > > */CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited. If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./* >
Received on Wednesday, 24 March 2021 04:27:03 UTC