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

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