- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 27 Mar 2022 13:49:20 -0400
- To: public-credentials@w3.org
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