On 24/03/2021 04:26, Bill Claxton, NextID Founder & Operations Director wrote:
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
So does the DNS and X.509. This is distribution not decentralisation
- ownership privilege belongs to the identity owner and not the issuer (which 'breaks the silo')

The Issuer is the owner of the attributes they assert. You do not own your driving licence, credit card or passport. They can all be removed from you by the issuer. Even your nationality can be removed from you by the government (as has been seen with ISIS adherents)


- identity owners have autonomy over what VCs they share and with whom they are shared

- identity holders have this autonomy, and this is the benefit of the VC data model


- verification services can be created and operate independently of issuers

a correct statement providing issuers make their meta data publicly available, otherwise not true.


- relying parties can verify a VC without reference to the issuer (and without being tracked)

The last point is moot. Academic papers have shown how people can be tracked in onion routing systems, so I would not say that tracking is impossible.



In brief - VC production, usage and verification are all decentralised

MAY all be decentralised. They do not have to be. So the use of "are" is incorrect

KInd regards

David

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

 

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