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

First off I just want to say thanks Dmitri, your email provided a valuable fresh perspective
on the issues being discussed and to me highlighted where the key disconnect lay in the perspectives being shared on this thread.

The reality is that across both the CCG and OIDF exists a wealth of incredibly smart people committed to making the digital identity technologies of tomorrow better. I hope by the time this thread is complete we can choose to work together across these communities.

> 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).

Agree we should discuss this in a separate thread, as a start though I dont think all forms of client authentication are harmful, its often beneficial over even just the course of a single transaction to be able to authenticate the client to some degree, for instance I would class PKCE under this umbrella some may not see it this way though.

> 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).

Yes again this is great to discuss.

> 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.

Yes I see this limitation, personally I would be willing to work on a proposal to put forward to them to see if they are willing to consider a more open model.


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: Dmitri Zagidulin <dzagidulin@gmail.com>
Sent: 26 March 2022 12:40
To: Kristina Yasuda <Kristina.Yasuda@microsoft.com>; public-credentials@w3.org <public-credentials@w3.org>; Mike Jones <Michael.Jones@microsoft.com>
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.

> 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.