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

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 27 Mar 2022 13:49:20 -0400
To: public-credentials@w3.org
Message-ID: <212f1cbc-d8af-a084-540f-af13cf1b97dc@digitalbazaar.com>
On 3/23/22 12:02 AM, Tobias Looker wrote:
> I for one will admit I was not around participating in this space during
> these days, so I'm not going to pretend I understand all the relevant
> history. But I would like to encourage others who are on this mailing list,
> who did participate in this work to please help in understanding it more.

They are! We are! You're hearing from them/us! :)

You might not agree with, or register everything they're saying at depth
(yet), but we're really trying to convey why some of us think that ignoring
the NASCAR problem and allowing the mandate of vendor registration are two
things that OIDC does today that are fundamental problems that, if not
addressed, will lead to centralization for DIDs and VCs.

> Apple only just implemented "sign in with apple" in a manner they claim is 
> compliant with OIDC in 2019 which appears refuted by OIDF [1].
> 
> Twitter have only just implemented OAuth2 [2] hence kind of OIDC.
> 
> Entities like facebook had facebook connect [3] prior to OIDC, so even if
> they didn't adopt OIDC there would have still been a "Login with facebook"
> option on relying party websites (in fact there was). Doesn't that show
> quite clearly why OIDC isn't the source of the problem here? Granted it can
> be a bigger part of the solution going forward, but blaming it for this
> seems entirely un-founded.

Sorry, no, strong disagreement on it being "un-founded".

Presuming these companies adopt OIDC with perfect conformance, that won't
change the fact that centralized social login via OIDC will remain.

Therefore, OIDC is not a solution to centralized social login; it just
re-entrenches the centralization using an "open standard".

That the OIDC community has known about these issues for well over a decade
and continues to not seriously work on either problem is concerning for all of
the people that have expressed their centralization concerns in this thread.

CHAPI, on the other hand, is a technology that attempts to tackle the problem
head on (albeit imperfectly, but working for 95%+ of the browser population
ain't bad when the alternative is centralization).

VC API, on the other hand, depends on the VP exchange protocol in use to
establish the connection between the Holder and the Issuer... not the Wallet
Vendor and the Issuer. The latter is a centralization danger.

OIDC at best does not combat centralization and at worst, promotes
centralization... especially given the strong evidence we see of it being
adopted by big tech AND the continuance of centralization in social log in.

> In fact it seems likely that without OpenID Connect the average relying
> party website would support less login options then it does today (meaning
> even less user choice and worse outcomes for user privacy), because the
> relying parties would have had to implement bespoke protocols for each
> provider (like facebook connect).

No, those providers provided libraries that implemented their bespoke
protocols and web developers happily integrated those with their websites,
contributing to the centralization problem.

While OIDC has made library integrations easier, and has been successful in
enterprise IdP selection (because people just point to their own
infrastructure), OIDC has done nothing that has been effective to change the
centralization dynamic. It's for closed ecosystems, not open ones.

> The overall point I'm trying to make is that the perception that "BigTech"
> had this highly organized effort to rally around a protocol, make it 
> anti-competitive to their own gain

If you think that's the argument, then you are not understanding the dangers.
I tried to come at this from an entirely different direction in this post (by
using a game design analogy):

https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0279.html

The argument is that protocols can have design characteristics that lead to
centralization outcomes. Two of them are:

* If you don't enable user-driven provider registration
  and selection, RPs will be forced to hard code to a
  handful of providers, which they will force on their
  users, which leads to provider centralization.

* If you enable mandatory provider registration with RPs,
  even if as an optional feature, RPs will implement it as
  the path of least resistance, which leads to provider
  centralization.

Some BigTech players are savvy enough to take advantage of centralization
flaws in protocols to achieve vendor lock-in. There are very few economic
forces that punish that kind of behaviour, and many more that reward that sort
of behaviour.

It takes just as much large-scale coordination as a murmuration of Starlings
as they all fly together and abruptly change direction as if there is a
greater force controlling them. That is, next to no large scale coordination
is needed; it happens in a decentralized fashion with very simple rules.

That said, we ALSO have a number of examples of coordination among the big
providers. You asked for people to "help the community understand the history
more". Here's a bit of that history that I personally lived through, that's
documented, and summarized here:

http://manu.sporny.org/2016/browser-api-incubation-antipattern/

That was Apple, Microsoft, and Google collaborating with each other to destroy
payment provider selection in the Web Payments API. Anders and I lived through
that... and I made a number of the well intentioned but misguided arguments
that you are, Tobias, as they undid 5 years of decentralization work over the
course of four months. The mistake I made back then was completely
underestimating the lengths that BigTech are willing to go to, how little
engineers speak up when they see big companies do bad things, and how fragile
specifications are to centralization.

So, yes, BigTech does rally around protocols that give them an advantage in
the market, especially if it enables them to perform vendor-locking and be
among the circle of winners.

> there are literally thousands of OpenID providers beyond just big tech who
> collectively support hundreds of thousands of relying parties a day, this
> landscape is incredibly distributed to say the very least, so again, the 
> blame here is being put in the wrong place.

Citation required with a claim like that.

Show me how those thousands of OpenID providers are participating in social
login today using OIDC.

> Are we missing a mediation layer that allows the End-User to participate
> more in the choices they see when they go to login on the web? Yes - But
> this is not clear cut, there are a tonne of issues to work through in order
> to get this right, at web scale.

Good, at least we're aligned on this. It is not clear cut, and there are
issues to work through in order to get this right, at web scale.... but the
only way we do that is for you to start (non-hyperbolically) listing all of
the issues so we can start talking about them... and you might just discover
that some of us have already considered those things and have mitigations, or
(even better) you uncover something we haven't thought about before and we
address the problem.

There are a list of things that OIDC4V* /could/ do that would get me behind
the protocol, and I've been repeating them throughout this thread.

What are the list of things that CHAPI needs to do that would get you behind
that protocol?

The real apples-to-apples competition is between VPR + VC-API, some variation
of OIDC4V*, and WACI + DIDCommv2, AFAICT.

> Does it require throwing out OIDC, no in my opinion it does not, the
> mediation layer can be added,

Oh, yes, there is a way that OIDC can actually provide IdP choice and a
mediation layer is one of those ways.

Now all we need is for the OpenID Community to get on board with the mediation
layer as a requirement. Do you think a substantial portion of them are going
to do that?

> in fact it has been done before via
> https://github.com/openid/accountchooser.com

Abandoned 8 years ago, with only one developer contributing, and it never had
a chance because the technologies that CHAPI uses today didn't exist back
then. That said, CHAPI is the spiritual successor for that program.

Why did the OpenID Foundation abandon that work... and do all of those reasons
still hold today? Why is no one asking those questions?

-- 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/
Received on Sunday, 27 March 2022 17:49:38 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 27 March 2022 17:49:40 UTC