- From: Dmitri Zagidulin <dzagidulin@gmail.com>
- Date: Fri, 25 Mar 2022 19:40:12 -0400
- To: Kristina Yasuda <Kristina.Yasuda@microsoft.com>, "public-credentials@w3.org" <public-credentials@w3.org>, Mike Jones <Michael.Jones@microsoft.com>
- Message-ID: <CANnQ-L6JbY8hRZt3g7=UKVZbPk4YazWrZs0Wj359FLh_e+utLQ@mail.gmail.com>
> That some RPs didn't facilitate that choice enabled by OpenID Connect isn't a valid reason to criticize either the OpenID Connect protocol or the community behind it. > Some of the points discussed in this thread openly criticize specifications being worked on outside the CCG. Kristina, Mike, As one of the voices in this discussion that may have come across as criticizing the OpenID family of protocols or its community, firstly I'd like to apologize, since I certainly do not intend to criticize either the protocols or the community as a whole. I joined in the discussion to offer critiques of a couple of very particular components of OIDC-related protocols, ones that I hope are fixable (although I suspect it will take quite a concerted effort on all of our parts). And I speak out of deep love and respect for, and experience with, all things OIDC. I make my arguments as an implementer -- I've been integrating OIDC and OAuth2 into almost every single project I've worked on (including in conjunction with other protocols like CHAPI) since 2016, and this is likely to continue for the foreseeable future. I consider myself a part of the OIDC community, in addition to being a part of W3C/CCG, DIF, IETF, and other standards bodies. And I certainly don't mean to imply that any of these (as I see them) current shortcomings of the protocol are present because of any strategic monopoly-focused design, or lack of knowledge or experience. I agree with Mike, that when OIDC was being created, it was very much designed as a method to bring significantly greater de-centralization and user choice to the tech landscape. And I also get why those designs went astray -- the historical tragedy of large email providers pulling support for WebFinger (and thus ruining people's hopes for wallet selection/solution to the NASCAR problem), is something that I think does not get talked about enough, in our industry. All of that said, I also agree with a couple of the points in Manu's original thread that started this discussion. In the context of credential wallets, given the current tech landscape, dev capabilities, and limitations imposed by OS and browser vendors, I do believe that if OIDC protocols don't solve a couple of crucial issues, they are in danger of continuing the trajectory towards /more/ centralization and lock-in and less user choice. Specifically: 1) The widespread requirement of client registration. I know that OIDC Dynamic Registration exists (the OIDC-based cross-domain authentication protocol I designed for the Solid Project makes extensive use of DynReg). And that registration is not required for SIOP. Even given those things, I believe client registration poses a danger to the wallet landscape. One, it conflates (in one step) two very different things -- capability negotiation (which I agree with Tobias, is very useful), and client authentication. And Client Authentication Is Considered Harmful. (<- a topic I hope to discuss in a separate thread). Two, although Dynamic Registration exists, I very rarely see it actually allowed, in the wild. And I'd love to have more discussion of why that is (what technical and market pressures contribute to that tendency). 2) If we don't solve the Wallet Selection problem, our use of SIOP for presentation and OIDC4VP for provisioning will continue to significantly contribute to centralization and lack of user choice. I hope I don't offend anyone when I say -- our current mechanisms for wallet selection (custom protocol handlers and "universal" app links) are UNUSABLE. I say this as an implementer -- I still deploy those solutions to my customers, but I am deeply ashamed to be presenting them with those solutions, because they're terrible. And the only route I see to solving the wallet selection problem, is to simultaneously put together a community-run mediator/wallet-selector (which is what CHAPI strives to do) AND use all of the means at our disposal to convince browser vendors to add explicit support for wallet/idp selection to the user agents themselves. And no, FedCM will not save us. FedCM does not allow the user to specify which wallets they prefer. Instead, it continues the centralizing trend of Relying Parties throwing together a short list of wallets/IdPs they've heard of, in the hopes that it's enough. Despite the length of this email thread, I do very much think that this discussion is important (in the CCG, and all the other communities). Some outcomes I deeply hope will result from this thread: * I hope we continue the discussion of why client authentication of wallets is a serious anti-pattern. * I want more awareness and more pressure on platform vendors, to solve the NASCAR problem. It's seriously endangering the rollout of wallets currently. * I'd love to collaborate with Oliver and Tobias, to explore ways of combining CHAPI mediator for wallet selection with SIOP/OIDC4VP data models and protocols.
Received on Friday, 25 March 2022 23:41:41 UTC