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

Manu,

It seems pretty clear to me that we aren't getting anywhere in our latest email exchanges. I continually feel like on our points of disagreement we are talking past each other. Its become clear to me that recounting history (and yes I know it was my idea to invite more of it) is clearly going to have limited value when it is primarily two limited perspectives being shared. Im sure there is some hard fought truth in what you are saying, I respect it, but I simply don't agree, I've shared my perspective and you have yours. I find it fruitless to continue to engage in a dialog, much of which, attempts to characterise the motives of people and organisations, who are members of this and wider communities, as being complicit, ignorant or worse. As a community we should endeavour to spend less time criticising others and instead focus on solving problems. To that end I'm going to try and focus on the things I think we agree on and I suggest Dmitri's latest response is the best place to start with this (im essentially restating his points below + a couple more):

- Its clear that we need to work on a mediation layer for whatever protocol we use for same-device flows. A polyfill approach like CHAPI is an option, however there are concerns being shared by numerous people on how this works today, ones that appear to keep being overridden in this thread and in the spreadsheet. I'm going to try work on a way to better communicate these outside of the context of pitting SIOP against CHAPI, because all that leads to is a tit for tat style dialog, rather than one that is focused on finding solutions to the outstanding problems.

As a parallel approach I would also like us to explore putting forward a proposal to FedCM, its not every day that the browsers work on primitives
in this area, so the time feels right to have the conversation. I offer the following as a starting point https://docs.google.com/document/d/1zxRFhF6qwGTCOYZ6UwTutbXVyRiD3krXyfFkcp_6t98/edit, I expect the proposal to be controversial, but can we please focus on productive commentary in this document *if* there are people who are interested in making one?

- Separating out the protocol from the mediation layer appears to have brought some clarity so I will try to continue to help make this clearer in the spreadsheet.

- Its clear that the exchange protocol needs to account for capability negotiation between the involved parties (e.g RP and wallet during credential presentation), whether that be accomplished via something like client registration or via other means. Its very hard to compare when this doesn't exist in CHAPI and VC API today.

- We need to have a discussion about client authentication, I dont know how to describe this more generally than by using the OAuth2 language.

- I think being able to share a security model and E2E sequence diagram for how these different protocols are assumed to work would also help massively in the conversation, im willing to commit to producing one for OIDC CP / OIDC4VCI as a starting point and talking it through if others are happy to do it for the other protocols?

Thanks,

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>



Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

[Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>

[Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>

[Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

________________________________
From: Manu Sporny <msporny@digitalbazaar.com>
Sent: 28 March 2022 06:49
To: public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.


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/