Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

BTW, something odd happened to the mailing list ordering, so sending this
again. This was also flagged as containing inappropriate content by the
mailing list operator which I don't feel that it does.

Writing this from my personal email account since I want to comment on a
few things. Also want to point out that any opinion shared here is my
personal opinion.

I think my previous email didn’t go through, so please apologize if this
may have been received twice (didn’t find my previous email in the archive,
so sending again).

> What would be more beneficial is for someone to produce a pros/cons matrix
> like we did for "Protecting VCs using pure JSON JWTs vs. VC-JWTs vs.
Linked
> Data Proofs":
> https://w3c.github.io/vc-imp-guide/#benefits-of-jwts
> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs

I don't think having a comparison table like this is useful or can be done
in a meaningful way. Since I believe that any of the credentials exchange
protocols can be implemented in
a more or less centralized way. This includes OIDC, CHAPI and the Aries
protocols. IMO, the degree of centralization is a design decision and none
of the protocols can exclude this design on a pure technical level. Those
design decisions are driven by business, regulatory, technical, UX and
other requirements. BTW, I’m not advocating for centralized models.

Why it is so hard to come up with a comparison table that puts those
protocols on a spectrum shows the following diagrams (based on CHAPI, using
different approaches for managing access to data and keys). There are
certainly many other ways this can be done. Note, that I don't want to
suggest centralization is inherent to CHAPI, in that case it was merely a
design decision. Similar diagrams can be created for system architectures
that use OIDC or Aries protocols.

Diagram here:
https://raw.githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg
<https://raw..githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg>

I also want to point out that SIOPv2 does not require a centralized
component, in the same way as CHAPI and Aries don't require centralized
components. If we want to talk about "centralization dangers", then we
should not look at one specific protocol.

I also want to comment on the points below.

> 1. Eliminate registration -- if you require wallet
>    registration, you enable centralization.

SIOPv2 does not require wallet registration as other people have also
pointed out.

> 2. Eliminate NASCAR screens; don't allow verifiers to
>    pick/choose which wallets they accept. If you allow
>    either of these things to happen, you enable
>    centralization.

IMO, solving NASCAR in a satisfying manner always requires support from
platform/OS and/or browser vendors if you don't want to provide unfamiliar
or broken UX for end users. Some of the problems are platform-specific
handling of custom URL schemes and short-lived browser storage.
Technically, SIOPv2 can solve NASCAR by using openid:// but we know that
won’t work well on iOS. Other SIOPv2 discovery options exist and the spec
allows room for innovation. Even a convergence with the CHAPI model may be
possible, e.g., get SIOPv2 OPs config via CHAPI.

There might be promising other approaches such as handling mime-types for
presentation requests on mobile platforms but I don't know if anyone has
implemented it in a production environment. The idea is to assign a
mime-type for presentation requests.

I believe CHAPI can be great but this is why I believe CHAPI doesn’t solve
NASCAR either yet (at least not in a satisfying manner):

1. (ASSUMPTION) CHAPI currently relies on a mediator which is a hosted
polyfill under authn.io. This polyfill is permissive (in terms of wallets)
but governed by a private company. I do believe that the current
implementation is fine regarding privacy, so no tracking and will stay
permissive. But websites could decide to host their own less permissive
polyfill which can limit mediation to certain credential handlers (i.e.
wallets). This is possible as long as the polyfill doesn’t get implemented
as a native browser feature which requires browser vendors support.  If it
is implemented by browser vendors, wouldn't this mean they are in control
again and can decide who they would let in? Correct me if I’m wrong here.

2. Registered credential handlers live in the browser storage and if that
gets wiped, users need to re-register their credential handlers which
involves going back to wallet vendors’ web pages.

I’d like to understand how and when the CHAPI community wants to solve 1.
and 2. Then, CHAPI will definitely be a good option to solve NASCAR.

> 3. Eliminate the concept of "App Store"-like in-wallet
>    "Marketplaces". If you do this, you put issuers at a
>    natural disadvantage -- pay to play to get listed
>    in a wallet's "Marketplace".

If some of the wallets decide to do that, then it is their design decision.
There is no requirement in any of the OIDC4SSI specs. However, any wallet
can choose to implement such features but there is nothing in CHAPI, Aries
that would prevent anyone from doing that in the same way you may have
observed.

If you read this far, then the main point I want to get across is that we
should avoid denouncing certain protocols as bad or evil and stop using
polemic arguments. If a technology is used in a good or bad way depends on
design decisions made by technology providers. For example, governments can
act as a forcing function to provide requirements in the form of
regulations that are more permissive (my hope for eIDAS 2..0).

Thanks,
Oliver



>
>>> ---------- Forwarded message ---------
>>> From: Manu Sporny <msporny@digitalbazaar.com>
>>> Date: Fri, Mar 18, 2022 at 5:49 PM
>>> Subject: Centralization dangers of applying OpenID Connect to wallets
>>> protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])
>>> To: <public-credentials@w3.org>
>>>
>>>
>>> I'm taking all of my hats off and saying the rest as a "concerned
>>> citizen and
>>> computer scientist". Take it as personal commentary, for whatever that
>>> is worth.
>>>
>>> I expect much of this to be controversial... and result in an unavoidable
>>> permathread. :)
>>>
>>> TL;DR: It is hopelessly naive to think that OpenID Connect, THE protocol
>>> that
>>> centralized social login to 3-4 major tech companies, only requires
>>> "small
>>> changes" for self-sovereign identity and is a "doorway" we should
>>> gleefully
>>> step through.
>>>
>>> On 3/17/22 5:45 PM, Kaliya Identity Woman wrote:
>>> > Yes - and I agree with the note following this one on the thread that
>>> they
>>> > are meeting different needs use-cases.
>>>
>>> It's all a matter of perspective, isn't it? :)
>>>
>>> When you get down into the details, sure you can argue that some
>>> protocols are
>>> addressing different needs/use-cases, but it is also undeniable that
>>> every
>>> single one of the protocols can move a Verifiable Credential from point
>>> A to
>>> point B. In that way, they're directly competitive with one another.
>>> That's
>>> not an interesting debate, though; it's at the wrong level -- too meta.
>>>
>>> What would be more beneficial is for someone to produce a pros/cons
>>> matrix
>>> like we did for "Protecting VCs using pure JSON JWTs vs. VC-JWTs vs.
>>> Linked
>>> Data Proofs":
>>>
>>> https://w3c.github.io/vc-imp-guide/#benefits-of-jwts
>>> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs
>>>
>>> Until we get to that level of detail, I expect we'll not make much
>>> progress on
>>> the wallet protocols topic.
>>>
>>> > The fact is that there is a huge opportunity to really leverage the
>>> "OIDC"
>>> > "doorways" that exist all over the web (a protocol that is literally
>>> used
>>> > a billion times a day...you know some real adoption) to exchange VCs -
>>> with
>>> > some small changes.
>>> >
>>> > AND people in this group seem to be "deathly afraid" of that work
>>> because
>>> > it isn't home grown here alone in isolation and focused on web only.
>>>
>>> I... just... don't even know where to start. I disagree with every
>>> concept in
>>> the previous paragraph. :)
>>>
>>> I can't speak for anyone else in this group, so I'll just speak for
>>> myself:
>>>
>>> It is hopelessly naive to think that OpenID Connect, THE protocol that
>>> centralized social login to 3-4 major tech companies, only requires
>>> "small
>>> changes" for self-sovereign identity and is a "doorway" we should
>>> gleefully
>>> step through.
>>>
>>> Login with Google/Facebook/Apple/Microsoft, those "billions of times a
>>> day"
>>> usages... are all coerced logins. We have no choice but to use the big
>>> tech
>>> vendors. That is not a world I want to contribute to.
>>>
>>> We are not "focused on web only" here... though it is an effective
>>> "gotcha!"
>>> talking point that seems to not be questioned when uttered ("I mean...
>>> the
>>> word "WEB" is in World Wide Web Consortium! What else could they be up
>>> to over
>>> there!?"). The phrase is disingenuous, I really wish those uttering it
>>> would
>>> stop... but you can't blame them, it's an effective way to get people who
>>> don't know any better nodding in agreement with whatever "non-Web" thing
>>> you're going to say next.
>>>
>>> I am "deathly afraid" of the work, because people are rushing into it
>>> without
>>> thinking deeply about the consequences. So, "Nope!":
>>>
>>> I refuse to just go with the herd and gleefully re-cement centralization
>>> in
>>> this new generation of identity technologies.
>>>
>>> I refuse to trust that things will be different this time because the
>>> same
>>> people that created OpenID Connect have learned their lessons and are
>>> doing
>>> things differently now.
>>>
>>> ... and I refuse to accept your mischaracterization of this community,
>>> the
>>> good faith efforts that they've put forward to coordinate where they
>>> can, or
>>> why some of us remain sceptical of some of the other wallet protocol
>>> efforts
>>> going on right now.
>>>
>>> It is possible for all of us, across all communities, to act in good
>>> faith and
>>> still disagree on the path forward.
>>>
>>> I certainly don't think for a second that the vast majority of people
>>> involved
>>> in OpenID, DIF, CCG, IIW, or RWoT are acting in bad faith. Misguided,
>>> possibly
>>> (including myself!), but not this "Not Invented Here Tribalism"
>>> narrative that
>>> seems to be so popular. I see a bunch of people, across each "silo",
>>> doing
>>> their best to solve hard problems given all of the pressures of their
>>> work and
>>> home life. Full stop.
>>>
>>> Going back to OpenID being applied to Verifiable Credential Exchange.
>>> There
>>> are three fatal flaws that need to be overcome for it to be a good idea:
>>>
>>> 1. Eliminate registration -- if you require wallet
>>>    registration, you enable centralization.
>>>
>>> 2. Eliminate NASCAR screens; don't allow verifiers to
>>>    pick/choose which wallets they accept. If you allow
>>>    either of these things to happen, you enable
>>>    centralization.
>>>
>>> 3. Eliminate the concept of "App Store"-like in-wallet
>>>    "Marketplaces". If you do this, you put issuers at a
>>>    natural disadvantage -- pay to play to get listed
>>>    in a wallet's "Marketplace".
>>>
>>> Rather than seeing solutions proposed to the problems above, the OpenID
>>> specifications seem to be doubling down on enabling the three items
>>> above.
>>>
>>> Out of CHAPI, DIDCommv2, and OpenID... OpenID is the most centralizing,
>>> worst
>>> solution for Verifiable Credential Exchange on the table today.
>>>
>>> That is not to say it can't be fixed, but I have yet to see a proposal
>>> that
>>> addresses all three items above.
>>>
>>> > There is a lot of "othering" of work that isn't CCG. Because that work
>>> is
>>> > less "pure".
>>>
>>> No, there are concerns related to the technical underpinnings of OpenID
>>> that
>>> lead to centralization that have yet to be addressed by the current
>>> proposals.
>>>
>>> The only Othering I'm seeing going on here is what you're doing. Casting
>>> some
>>> vague subset of the CCG as this irrational, web-only, not invented here,
>>> tribal silo and going after community volunteers that are not doing what
>>> you
>>> want or meeting on your schedule.
>>>
>>> I've known you for many years, Kaliya -- you're better than this and are
>>> usually a bridge builder and tireless advocate for open lines of
>>> communication. I know you're frustrated, we all are, but I don't think
>>> the way
>>> in which you've chosen to engage is going to result in what you want.
>>>
>>> Again, just my $0.02 as a community member.
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>> Founder/CEO - Digital Bazaar, Inc.
>>> News: Digital Bazaar Announces New Case Studies (2021)
>>> https://www.digitalbazaar.com/
>>>
>>>
>>>