W3C home > Mailing lists > Public > public-credentials@w3.org > March 2022

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 26 Mar 2022 16:32:26 -0400
To: public-credentials@w3.org
Message-ID: <b9bf9931-8a73-9913-570e-d52054c8b1c7@digitalbazaar.com>
On 3/20/22 8:56 PM, Tobias Looker wrote:
> There was never any assertion made that this mechanism was suitable for 
> "same-device", hence why the description starts with the words
> "cross-device".

Yes, understood... but that's not the point I was making, which is below:

> The list supplied was to describe the different ways a request can be
> passed to a wallet using SIOP v2. What it does highlight is that SIOP v2
> supports more mediums to hand a request to a wallet than the CHAPI model
> which shows in my mind why the protocol (OIDC/SIOP) should be separate from
> the mediation layer that gets added on top when you are in an environment
> like a browser that requires wallet chooser style mediation.

Disagree on "more mediums" being a good thing.

Here's the point:

Generally speaking, cross-device wallet invocation is a solved problem -- just
use a QR Code and /any/ of the presentation request mechanisms. Done. Everyone
(W3C/CCG stack, OpenID/DIF stack, Aries stack) have already converged on that

That's not the point of contention, the point of contention is how OIDC/SIOP
claims to solve same-device wallet invocation when every solution put forward
has unworkable drawbacks with no suggestions about how to get around those
drawbacks. Even worse, and when you put all of those SIOP solutions together
-- no one is using them in a unified way and we're completely hand-waving over
the centralization issues with mandatory OIDC registration for "high-value"
use cases. I'm not talking about dynamic client registration, which might be
ok, I'm talking about the Issuer going: "I need to know that this is an Apple
Wallet I'm connecting to". <-- that will lead to market centralization.

> Are we fundamentally comparing the wrongs things here? Should we instead
> be comparing VPR + VC API to the OIDC protocols?

Yes, probably... but we still need to know how OIDC is proposing to do same
device wallet invocation without hand waving over it. In an attempt to try and
narrow in on this, I've added two more columns to the W3C CCG Wallet Protocol
Analysis document: "OS Protocol Handler" and "OS URL Handler", I suggest we
move OIDC/SIOP to the Presentation Exchange section and focus purely on
protocol... but am unsure if you want to extract just the wallet invocation
bits of it before we do that? I leave moving that over to you... I think we're
getting some really useful refinement on this point.

For same-device wallet invocation, the apples-to-apples comparison is probably
CHAPI vs. OS Protocol Handler vs. OS URL Handler.

I'm not sure how the query parameter passing w/ OIDC is going to work on the
presentation exchange page, but given that we already have OIDC4VC1 and
OIDC4VP on there, it might work out. What do you think?

>> The issue isn't cross-device... it's same device wallet invocation (which
>> is a
> very common use case).
> 100% agree that the NASCAR problem is mostly an issue for same-device
> style interactions, but are you saying cross-device use-cases have no value
> and we shouldn't design a protocol that works for that too?

No, I'm saying that we should solve for all of these use cases that we know
about because they're all important. We need to support:

1. Same-device web wallet.
2. Same-device native wallet.
3. Cross-device web wallet.
4. Cross-device native wallet.

1 and 2 are challenging, 3 and 4 are easy (just use a QR Code).

If we do not have an open wallet ecosystem solution for all of those, we
should expect a repeat of the centralization that OpenID Connect established
in social login.

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Received on Saturday, 26 March 2022 20:32:43 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 26 March 2022 20:32:44 UTC