W3C home > Mailing lists > Public > public-credentials@w3.org > March 2021

Re: The "self-sovereign" problem (was: The SSI protocols challenge)

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 
- 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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:11 UTC