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

Michael – I fully agree with your definition of a Digital Identity.  However, I have to completely disagree with your definition of a decentralized identity, as it stands.

First and foremost, without a definition/clarification of “Verifiable”, both of your statements are ambiguous.  I don’t understand what it means, in this context, to be verifiable – especially since in the context of identity that term is used for many different aspects.

Next, even if we agree on a definition of “Verifiable’, it’s not clear from your first statement what part(s) of the Digital Identity have been “verified”.   Are you saying that all aspects of the “Associated Digital Identity Data” have been “verified”?  That the aggregation is a “verified pairing”?   What??

It’s a good start, but I think we can do better.

Leonard

From: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>
Date: Tuesday, March 23, 2021 at 11:04 PM
To: David Waite <dwaite@pingidentity.com>, "Jim St.Clair" <jim.stclair@lumedic.io>
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Drummond Reed <drummond.reed@evernym.com>, sankarshan <sankarshan@dhiway.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Subject: RE: The "self-sovereign" problem (was: The SSI protocols challenge)

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhyperonomy.com%2F2021%2F03%2F23%2Ftdw-glossary-the-big-picture%2F&data=04%7C01%7Clrosenth%40adobe.com%7C510823c7708e4eef7fd708d8ee718acf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637521518724121463%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V3gQLVypISNSakA3LtkLLL%2F%2FD4wVhOSnnWmvJNsOIxE%3D&reserved=0>

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsignin.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C510823c7708e4eef7fd708d8ee718acf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637521518724131418%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B49L5RfDwBpHd41hHpyDMLrQyY5Ds0OoEOndm2BHppQ%3D&reserved=0> 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 12:46:31 UTC