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

On Fri, Mar 18, 2022 at 12:21 PM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> > In your opinion, does SIOP help with the NASCAR problem?
>
> So, I can definitely speak to this -- No, SIOP does not solve the NASCAR
> problem, unfortunately. And this has to do with the limitation OS vendors
> enforce, both on mobile devices and on the desktop. There are two problems
> with the current `openid://` / custom protocol handler approach.
>
> 1. Terrible initial UX. Meaning, if a typical user clicks on an openid://
> URL on the desktop or on mobile, and they don't have an app installed that
> handles it, NOTHING HAPPENS. Literally nothing happens. There's no smooth
> guiding to a marketplace to install a handler, or anything like that. But
> this is a minor inconvenience, compared to the next one.
>

I believe you can catch this via javascript, but you may still get a
browser-supplied error prompt. I haven't tried in a while.


> 2. If more than one app is registered as a handler for openid://, and a
> user clicks on the link, the behavior is *undefined* (at least on IOS).
> And this is a very well understood problem in the SIOP community -- if you
> look at the SIOP v2 spec,
> https://openid.net/specs/openid-connect-self-issued-v2-1_0-03.html#section-7.5.1
> :
> "Usage of custom schemas [like openid://] as a way to invoke a Self-Issued
> OP may lead to phishing attacks and undefined behavior. ... Any malicious
> app can register the custom schema already used by another app, imitate the
> user interface and impersonate a good app. When more than one Self-issued
> OP with the same custom schema has been installed on one device, the
> behavior of Self-Issued OP is undefined."
>
> This is a huge problem, that the community is still strugglign to solve.
>

To be honest, I don't see this being solved without a first-class
interface for javascript and native apps, similar to what WebAuthn has
created for pure authentication credentials. A successful launch of
Europe's wallet initiative may eventually help apply some pressure here.

The platform ultimately controls invocation of URLs, be it the browser or
the OS underneath. Applications themselves are typically sandboxed from
introspection of other installed applications as such would be a big
privacy risk as well as making a whole range of security exploits easier to
perform.

If a platform DID have first class support, it would solve other issues,
such as how to more tightly filter requests to a wallet which indicates it
has the technical capacity to answer it, or even to wallets that hold
credentials which would meet the stated requirements.

Today, the best pitch we have (other than scanning a QR code with your
chosen wallet on another device) is app links maintained by a trust
framework. So for example, if a group of issuers, verifiers and wallets all
wanted to provide merchant age verification they might define the exact
credential type and format and other specificities and then create an app
link that all verifiers would be to initiate an installed wallet. If no
wallet is installed, the app link itself is a descriptive page explaining
what needs to be done.

If _multiple_ wallets are installed, this is back in the realm of
platform-specific behavior - although they at least have defined that
behavior. The trust's list of supporting wallets may be treated as a
prioritized list, it may provide a user configuration option deep in
settings, or might give an OS prompt for desired option (including
potentially launching via an installed browser).

-DW

-- 
_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._