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

On Sun, Mar 27, 2022 at 2:40 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 3/24/22 1:37 PM, Oliver Terbu wrote:
> > Btw. app links are more secure than custom URL schemes and they are the
> > recommended way of invoking a native app. Interop is not established
> based
> > on the concrete app link, it is established through the
> > `authorization_endpoint` config parameter which can be any sort of URL,
> > e.g., an app link. There is no issue regarding interop since RPs don't
> need
> > to know the particular app link, just the place where to look for the
> > config parameter.
>
> Unless I'm missing something, App Links only work on Android mobile
> devices to
> invoke Android native apps, they don't work for web apps. On iPhone,
> universal
> links are hobbled outside of Safari (just like you can't install a PWA
> through
> Chrome on iPhone).
>

As they are `https` links, they will launch the default browser (or
navigate the current browser) if no app is installed. For illustration
purposes, you can go to reddit.com on a phone without a reddit app
installed.

I can't speak to whether third party browsers have attempted to support
universal links on iOS. My understanding is that it is technically
feasible.

I imagine the more significant point is that third party browsers (by
omission or choice) may prevent the user's chosen wallet from launching, as
they are mediating the underlying platform.

So, they would be a solution if your wallet was a native app on the same
> mobile device (Android or iPhone), but they are NOT a solution if your
> wallet
> is a web app on the same device...


The case where the wallet is not a native app is a web fallback. That web
fallback is out of scope of SIOP and could be anything - it could be
information on how to proceed, links to a site with known wallets, it could
be a web wallet. It may also return control to the original requesting
party, at which point they could try additional mechanisms such as CHAPI
and DIDComm.

The assumption would be that such a universal link is part of some sort of
federation of issuers, relying parties and wallets - for the purpose of
issuing, requesting, presenting and verifying credentials.

The reality is that the invocation URI doesn't need to map to a native app
or web wallet. It could map to a hosted discovery service. However, such a
discovery service has not been described yet - so the idea is that this
looks more like an invited network (except on android, where you can
supposedly now advertise applink support for domains unilaterally).

There are certainly cases where you want a fully open (opt-in) network.
Universal links are recommended but custom URI schemes are still supported
for specifically that reason - and the spec defines
https://self-issued.info/v2 and "openid" as a custom URI scheme for that
purpose.

Unfortunately, registration of a URI scheme to a web app is limited - both
by browsers which do not support registration of protocol handlers, and by
other browsers and platforms not coordinating or honoring such
registrations.

The reality is every approach has trade-offs. I would argue no service
wanted a fleet of authentication buttons, but the lack of a "do what I
mean" button by the browser meant limited user choice was the next easiest
choice.

…or if you are on a non-Android or
> non-iPhone device -- like a Windows laptop/workstation.

What am I missing? Is there some universal implementation of App Link /
> Universal Links across all operating systems that I'm unaware of?


Windows supports this concept as an AppUriHandler . I don't know if there
is an e.g. freedesktop initiative to supply this sort of feature for the
*nixes.

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

Received on Sunday, 3 April 2022 08:54:14 UTC