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: David Waite <dwaite@pingidentity.com>
Date: Mon, 21 Mar 2022 17:06:44 -0600
Message-ID: <CA+3kW=ajdsu6q0R21ocJF+1NFJguko8vY1EMM7Yqtt14Kb2v2A@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Tobias Looker <tobias.looker@mattr.global>, "dzagidulin@gmail.com" <dzagidulin@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>
On Sun, Mar 20, 2022 at 2:32 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2022-03-19 23:52, Tobias Looker wrote:
> >  > Can you say more about those multiple ways? If I'm understanding
> correctly, there is just one mechanism that SIOP supports, and that is
> through a custom url protocol link. Is that not the case?
> >
> >
> > I guess it depends on what you constitute as being different in this
> context? What I meant here was the options that DW listed.
> >
> >
> > 1. Local Invocation via URL schemes or platform-registered HTTPS URL
> (e.g. universal links, app links)
> Or by misusing PaymentRequest which is a pretty good replacement for the
> eternally missing Web2App API:
> https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf

This seems to use URL schemes or claimed URLs itself, without any special
platform level support (e.g. listing applications which advertise a certain
characteristic for the user to choose). So it should have the same
trade-offs today, with a different API on front.

> > 2. Cross-device Invocation via QR code holding above initiation URL
> I'm not sure what that means.

SIOP requests are encoded within a URL with either a custom scheme or based
on a claimed URL.

Multiple SIOPs (aka wallets) can advertise with the platform support for
the same custom scheme or that they claim the same URL.

If you embed a SIOP request (URL) in a QR code, it is scannable by a third
party/system QR code reader on the other device, and the URL will be used
to launch an application (or for a claimed HTTPS URL, potentially the

If there are multiple applications which claim the same scheme or custom
URL scheme installed on the user device, we fall back to platform behavior
- that may be a prompt, a user configuration setting, a prioritized list,
or even some behavior like 'most recently launched'.

> >
> > 3. Cross-device invocation via wallet QR code reader
> In this case I guess that most existing wallets invoke the app directly,
> eliminating any dependencies on Web standards.

Yes, you basically ignore the custom URL scheme or claimed URL prefix and
just take the request out of the URL parameters. This skips platform
behavior for interpreting URLs and picking a registered application.

> Finally: A proper Web2App API would extend trough paired BLE so that
> mobile wallets could register their abilities and thus dealing with the
> NASCAR problem in the same way as same-device solutions.  In fact, it would
> be transparent for invoking Web applications where the wallets are situated.

URL launching across devices is certainly something we've thought about.
One common problem here is that the more the process looks like it is being
mediated by some party (such as the underlying platform provider), the more
people will assume the platform is protecting them from potential malicious
behaviors like phishing.


_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
Received on Monday, 21 March 2022 23:08:08 UTC

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