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

Thanks for the invitation Orie, I'll pile on.

As someone who once attempted to define "SSI" in a paper, and in the
process realized it caused more problems than solutions -- conflating
technologies, vaguely-aligned principles, and also misunderstanding of what
tech can/should achieve in implementing the apparent goals -- I decided to
only use the term "SSI" in scare quotes. It's a distraction to progress.



On Thu, Mar 25, 2021 at 12:44 PM Orie Steele <orie@transmute.industries>
wrote:

> I'll just leave these here:
>
> - https://en.wikipedia.org/wiki/Sovereign_citizen_movement
> -
> https://www.fbi.gov/news/pressrel/press-releases/fbi-expects-a-rise-in-scams-involving-cryptocurrency-related-to-the-covid-19-pandemic
>
> I would love to live in a world where "crypto" didn't imply "currency" and
> where "sovereign" didn't imply disconnected from social and legal norms...
>
> But sadly(?), we cannot control how language and culture evolve.
>
> I think we can all agree that governments, corporations and their less
> common form people (US centric joke), all need identity, confidentiality,
> authentication and authorization in the digital age.
>
> I personally find the term SSI brings almost as much baggage as ICO
> today... maybe it's time for us to find the SSI equivalent of DFI?
>
> The message feels like it should be on twitter, not the ccg mailing list.
>
> Apologies if my humor does not land well with you.
>
> Regards,
>
> OS
>
>
>
>
> On Wed, Mar 24, 2021 at 7:57 AM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
>> I should really have said that VCs & DID **need not** be
>> decentralized….but that doesn’t change things.
>>
>>
>>
>> Bill I have to disagree with your statements below as _*inherent*_ to
>> VC’s.  I agree they are properties that **can be** associated with a VC,
>> but they don’t have to be.  I think the thing that has you “hung up” is
>> statement #2:
>>
>> > ownership privilege belongs to the identity owner and not the issuer
>> (which 'breaks the silo')
>>
>>
>>
>> That’s key to SSI, true.  However, as myself and other have pointed out,
>> it is not key in any way to VCs which can be used with other types of
>> identity.   And once you recognize/accept that, then the rest of your
>> positions fall since they are all predicated on that single initial premise.
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *"Bill Claxton, NextID Founder & Operations Director" <
>> williamc@nextid.com>
>> *Organization: *NextID Pte Ltd
>> *Date: *Wednesday, March 24, 2021 at 12:29 AM
>> *To: *"public-credentials@w3.org" <public-credentials@w3.org>
>> *Subject: *Re: The "self-sovereign" problem (was: The SSI protocols
>> challenge)
>> *Resent-From: *<public-credentials@w3.org>
>> *Resent-Date: *Wednesday, March 24, 2021 at 12:27 AM
>>
>>
>>
>> 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)
>> 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:
>>
>>    1. A Digital Identifier, and
>>    2. 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%7C1ab657c5eeef42f3e5b408d8ee7d638b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637521569606502247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Jh7W4mBK%2FN%2FOhn76hHp%2BTfay02dysQuXMJ7DF9a6QB4%3D&reserved=0>
>>
>>
>>
>> *From:* David Waite <dwaite@pingidentity.com> <dwaite@pingidentity.com>
>> *Sent:* March 23, 2021 7:50 PM
>> *To:* Jim St.Clair <jim.stclair@lumedic.io> <jim.stclair@lumedic.io>
>> *Cc:* Leonard Rosenthol <lrosenth@adobe.com> <lrosenth@adobe.com>;
>> Drummond Reed <drummond.reed@evernym.com> <drummond.reed@evernym.com>;
>> Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
>> <mwherman@parallelspace.net>; sankarshan <sankarshan@dhiway.com>
>> <sankarshan@dhiway.com>; W3C Credentials CG (Public List)
>> <public-credentials@w3.org> <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.”
>>
>>    1. 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%7C1ab657c5eeef42f3e5b408d8ee7d638b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637521569606512206%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FAlElCrWlElaUAeLFrZAI4NFqgygtCcFX59ES3uwc%2BU%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.*
>>
>>
>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>