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

Thanks a lot, Dmitri! This means a lot.

I agree that wallet selection is a challenge of this space, where the SIOP spec allowed multiple options - 1) OIDC style registration for ecosystems where Issuers/regulators want to certify the wallets; 2) custom url schema - which does give a free wallet choice on Android mobile OS, though iOS is a challenge; 3) claimed urls (app links etc) - arguably more secure than custom url schemas but to allow free choice of wallet would require a mediator like in CHAPI. (+ invoking a QR code directly with a app camera)
+ other creative solutions. I think Affinidi has an interesting solution which allowed verifiers to detect which app the user is using and tailor QR codes to that app using headers.
(Note that SIOP accounts both native apps and web wallets, though currently there are more implementations with native apps)

SIOP spec does not claim that that these are perfect solutions, and we try to engage with mobile OS providers thought not really productively. So if there is a better solution to this problem (like CHAPI?), SIOP spec definitely should include those and I’d be happy to collaborate :)

I just don't think that SIOP not having a perfect solution to this problem just like any other spec with a similar scope means that SIOP is "centralized".

Just like I pointed out in another response, SIOP allows user to bring user's own identifier (DID being one option) as opposed having an identifier assigned by the third party provider, and OIDC4VP allows the user to present identity assertions to the verifier without verifier directly talking to the issuer.

This makes SIOP + OIDC4VP model VERY different from OIDC.Core. This is why the editors are confident this is the right step towards wider adoption of SSI.

Kindest Regards,
Kristina


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