- From: David Waite <dwaite@pingidentity.com>
- Date: Sun, 3 Apr 2022 02:53:49 -0600
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-credentials@w3.org
- Message-ID: <CA+3kW=Y4OVx_aYH-4nQ3KH2Bw05a2KW2ARhdK=7K9oO8ztMuQQ@mail.gmail.com>
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