- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 29 Mar 2022 16:46:29 +0200
- To: Tobias Looker <tobias.looker@mattr.global>, Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Hi Tobias, Thanks for this proposal! If this proposal requires browser vendor support, it must probably be built around WebAuthn. The proposal raises questions like how do you express capabilities? I have done something along these lines but in this system the capability is just a single URL which is supposed to represent a specific payment network: https://fido-web-pay.github.io/specification/#operation Even if this is of no interest, using card images is at least a bit cool :) A major issue is where the IdP/client code runs. Since all stuff including code that is downloaded from the Web by definition is untrusted, it seems that this model either depends on native code or on server code. Both of these schemes can attest which is a prerequisite for certification. Personally, I would go for server schemes because they are much simpler to deploy. I would also consider privacy aspects versus. The IdP doesn't necessary have to know to where you logged in. Thanks, Anders On 2022-03-28 10:06, Tobias Looker wrote: > 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 <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 <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/ <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 <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/ <https://www.linkedin.com/in/manusporny/> > Founder/CEO - Digital Bazaar, Inc. > News: Digital Bazaar Announces New Case Studies (2021) > https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/> > >
Received on Tuesday, 29 March 2022 14:47:46 UTC