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

On 3/18/22 3:41 PM, David Waite wrote:
> The death of the prior version of the specification (OpenID 2) has several 
> articles out there I'm sure, but the top reasons that user-centric
> identity failed were: - lack of a higher level system providing state and
> integration to automate the selection of an appropriate authentication
> process (including but not limited to the NASCAR effect)

Yes, and this is something CHAPI brings to the table in a way that works for a
very large percentage (95%+) of the market today. It is true that some of
those experiences could be improved (such as the one on Safari on iPhones),
and Brave (which is less than 1% of the market)... but to ignore the solution
because it doesn't work for 100% of the market is to throw the baby out with
the bathwater.

> OpenID Connect added the ability to run your own provider as a native app, 
> rather than hosted infrastructure. It also added the ability to aggregate 
> claimed attributes from other sources, so such a local agent could share 
> claims acquired from other parties at the end-user's leisure.

So, in your opinion, why isn't that the way we all exchange attributes these days?

> The goal of the current OpenID Connect efforts in this space (SIOPv2, 
> OpenID4VC, OpenID4VCI) are to adapt this existing system with changes and
> new protocol additions toward supporting technologies created by the CCG - 
> allowing use of DIDs as subject identifiers as an option instead of public 
> keys under SIOP, and allowing verifiable presentations to be used in
> addition to OpenID's own claim formats.

Sure, and this is useful for large concentrated identity providers to move
more useful claims around... it is an improvement over where the OpenID
ecosystem is today.

> Whether that goes to a a native app or a web-based wallet, and whether
> that wallet is created and maintained by a small startup, non-profit, tech 
> conglomerate or the underlying platform is really going to be determined
> by the market. I don't see this as being different from other protocol
> proposals.

Ah, see, this is where the disconnect is. Protocol decisions drive
behaviour... you CAN design protocols that have a natural tendency to
centralize, and you CAN design protocols that have a natural tendency to
decentralize SOME aspect of the ecosystem.

> I assume your goal is not about logins, but about having such companies 
> involved in certain ways, most likely visibility into interactions.

Yes, that's a particular concern that an increasing part of the population
cares about: "96% of US users opt out of app tracking in iOS 14.5, analytics find"

https://arstechnica.com/gadgets/2021/05/96-of-us-users-opt-out-of-app-tracking-in-ios-14-5-analytics-find/

> However, all four of those companies mentioned are platform vendors, which
> means at a certain point you are talking about regulatory protections and
> not technology.

Again, we don't need to just throw our hands up, there are useful options that
have bee put into CHAPI that nudge more decentralized outcomes than what you
are suggesting. This is not ONLY about regulation, though that can be a part
of the solution.

> As mentioned above, OpenID Connect has never mandated centralization -
> that has been driven by market forces.

Not entirely, it's also been driven by its technical design. When you do not
provide a mediation mechanism, like CHAPI does, then you force RPs to pick
winners, which then naturally puts centralization pressure on the market.

> This is similar to how IPv4 and HTTP weren't designed for ~40% of all
> internet traffic by volume ultimately being interactions with services by
> five companies.

Yes, and now there is a slew of new decentralization technologies that combat
that centralization -- IPFS, Storj, etc... and browsers that are adopting a
more decentralized stance such as Brave... all while companies that benefit
from that centralization produce solutions such as FedCM and FLoC to keep (or
double down on) their centralization advantage.

> The lessons to learn are what is limiting the desired reality. For
> instance, I have focused on ways to optimize the user (no software)
> onboarding experience and ways we might eliminate the need for NASCAR-style
> lists of providers (be them traditional hosted IDPs or vendor wallets).

Then, why are you not a fan of CHAPI considering it eliminates the need for
NASCAR-style lists of providers... and could even be used for OpenID provider
selection?

What solution are you proposing that provides a mediator?

> SIOP v2 can be invoked three ways: 1. Local Invocation via URL schemes or
> platform-registered HTTPS URL (e.g. universal links, app links)

CHAPI only applies to this one, the other two you listed are red herrings.
Dmitri already outlined why all of these options are problematic.

> The third approach is pretty common and does not use platform invocation.

Yes, but completely ignores the point of contention. CHAPI is about same
device flows... you can't suggest "just don't do same device flows" as a
solution to the stated problem.

> If you were speaking of 'registration' in the sense of say a CHAPI style 
> registration of a credential handler with a centrally hosted party or web 
> extension, the SIOP approaches currently do not have such a mechanism.

Yes, exactly this. That is the point of contention. So, asserting that SIOP is
a replacement for CHAPI completely misses the point -- they do different things.

> SIOPv2 defines a base 'openid' URL scheme which will send you to a wallet,
> but as a platform dispatch cannot filter based on wallet capabilities.

Yes, correct, and Dmitri has already outlined the downsides of the URL scheme
(multiple times) in this thread already, so I won't repeat what he said.

I'll also note that CHAPI provides hints on wallet features to the Holder
while keeping those features hidden from the RP (to avoid fingerprinting).
This is not something that SIOP, nor the OpenID stack does.

Again, privacy and decentralization matter... we can't keep hand waving over it.

> A group may declare their own URL scheme or app link based approach which
> is expected to have more stringent requirements for capabilities in order
> to improve the chance of user success. A single wallet can support multiple
> such groups.

Again, Dmitri listed the issues with these approaches.

> 3. Eliminate the concept of "App Store"-like in-wallet "Marketplaces". If
> you do this, you put issuers at a natural disadvantage -- pay to play to
> get listed in a wallet's "Marketplace".
> 
> 
> I'm not sure what this implies, or what you have seen.

I elaborated in a later email about marketplaces in my response to Tobias, did
that help explain what this item was about?

> OpenID4VCI is meant to be a generalized issuance protocol, e.g. people 
> authorizing an issuer to release a credential to a wallet. Initiation is
> via a URL (link or QR code presented e.g. by the issuer) which would
> describe to a wallet how to start that process.

This is for a same-device flow, you're describing cross-device flows. Again,
not the point of contention wrt. CHAPI vs. OIDC/OIDC4V*/SIOP.

Fundamentally, SIOP doesn't provide a mediator like CHAPI does for same-device
flows. How does SIOP enable holders to bring their own wallets (web or native)
for same device flows?

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Friday, 25 March 2022 00:34:15 UTC