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: Sun, 20 Mar 2022 12:49:22 -0400
To: public-credentials@w3.org
Message-ID: <004e9ad2-4f15-26a9-a43f-e56c8641da71@digitalbazaar.com>
On 3/19/22 5:30 PM, Tobias Looker wrote:
> Across all of these threads we appear to be wildly jumping from 
> considerations as they apply to credential issuance protocols and then as 
> they apply to credential presentation protocols.

The reason that is the case is because CHAPI and DIDCommv2 cover the gamut of
credential issuance and credential presentation, while the OpenID specs seem
to (for some reason I have yet to understand) do different things depending on
if you're issuing or presenting.

I wouldn't say the conversation is "wildly jumping" -- we're having multiple
conversations in parallel (and yes, it's a bit much). However, these are all
considerations that need to go into a holistic solution.

That said, I take your point about focusing on the technical primitives; it is
part of the discussion that's currently a bit more chaotic than it needs to be.

> SIOP currently supports multiple ways to invoke / send a request to a 
> wallet to ask for presentation of credentials, however when the relying 
> party is a website, without a consistent *browser style* mediation layer 
> that allows an End-User to register what wallets they use like in CHAPI,
> it does not meet the "open wallet ecosystem" goal?

Yes, correct, because it ducks the point of contention instead of addressing
it directly: None of the current OpenID protocols work for people using their
mobile phone to pick up a credential on the same device, nor do they work for
people using their laptop/desktop to pick up a credential on the same device.
CHAPI solves this particular problem, DIDCommv2 and OpenID do not.

Remember where this conversation started... with Kaliya insisting that some in
the community were being irrational in their "not invented here tribalism" by
not adopting OpenID. The real reason is more nuanced -- it's that OpenID
doesn't seek to solve the "open wallet ecosystem" goal.

This thread is shedding light as to why -- OpenID isn't a solution to,
arguably, the most important requirement that our community faces -- enabling
an open wallet ecosystem with respect to the primary way people use their
mobile devices when discovering something new today (open a browser, do
something in-browser).

I guess you could argue that DIDCommv2 only solves that goal if you have two
devices with which to engage... except, we've seen examples of DIDCommv2 being
bootstrapped over CHAPI (and that is a valid way, IMHO, of solving the open
wallet ecosystem goal). We've gone so far as to try and establish how to do a
protocol upgrade from CHAPI+VPR to DIDCommv2 here:


OpenID does none of these things and instead demands that the user has to be
engaging two devices at all times in order to scan a QR Code (same as
DIDCommv2 w/o CHAPI) and then further hammers the centralization nail in by
saying: "Oh, and wallets need to be registered with the issuer in some way
during issuance... and probably for verification, too!" It's that last thing
that makes OpenID the worst of all three options.

> The reason I added the caveat "when the relying party is a website" here, 
> is how does CHAPI help achieve an "open wallet ecosystem" when you are 
> doing a cross device presentation (e.g in-person)? IMO it doesn't which 
> highlights the fact we perhaps need to be clearer about what user journeys 
> we are talking about when.

Yes, point taken. CHAPI is NOT a solution to that problem... a QR Code with
some sort of rendezvous payload is... but invoking a interaction in that way
is largely a solved problem (for a use case that's important, but not the
point of contention).

Wouldn't it be nice if you didn't HAVE to have two devices to pick up a

> Also I think the importance of the existence of a mediation layer like 
> CHAPI is different in credential presentation flows vs issuance flows, for 
> example in issuance, a CHAPI mediation layer is only used if you start
> from the issuers website AND your wallet is installed on the same device
> and you need some way to invoke it.

Yes, the use case otherwise known as "People using the Web on their mobile
phone to get stuff done." or "People using the Web on their desktop/laptop to
get stuff done." -- It's the primary interaction mechanism that many of us
engage in every day.

I don't know about ya'll, but I don't regularly jump from my desktop browser
to my mobile device to accomplish a single task. The one exception is
Multi-Factor Authentication -- and while it's necessary to have that happen on
a different device... it's not necessary for me to pick up a credential using
a different device. In fact, that's an annoying inconvenience that is being
driven by self-imposed technical shortcomings in OpenID and non-CHAPI-DIDCommv2.

Hope that helps shed more light on where all of this is coming from... will
respond to your three technical points in the next email.

-- manu

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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:29 UTC