- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 3 Apr 2022 14:58:21 -0400
- To: public-credentials@w3.org
On 4/3/22 4:53 AM, David Waite wrote: > As they are `https` links, they will launch the default browser (or > navigate the current browser) if no app is installed. Yes, but keep in mind that when they go to that URL, the assumption here is that it's either a URL that is solely under the wallet provider (with text that says: Download this Wallet from the App Store!), or under a federation of wallet providers (with text that says: Here are some wallets in the App Store that you can download!). There is zero ability to use a web-based wallet when you use an App Link UNLESS there is no native wallet installed for that URL, ever. Also remember that the second that the user installs a native app that registers for the URL, you lose the ability to use web-based wallets... AND attackers can (legitimately) redirect traffic away from your App Link. It is possible for other apps to redirect people from your wallet URL to their wallet app; a form of corporate URL take over (by design -- because you can't do the federation thing w/o this ability to squat on other people's URLs). With CHAPI, you don't have that attack vector or fragmentation -- there is a sensible set of defaults that a RP can set (if there are no wallets installed), and if there is at least one wallet installed the Holder is provided that choice, whether it is a web-based app or a native app, because they're the one that chose to register that wallet in the first place. > 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. There are many things that are technically feasible in iOS that Apple has forbidden. For example, it's forbidden to install a Progressive Web App on iOS unless you're using Safari. It's also forbidden to use any other browser engine than Apple's WebKit on iOS. CHAPI works in all major browsers on iOS, albeit with a scary "Allow authn.io to track you?" question when registering and 3rd party storage expiration -- both of these are addressable via a "run in first-party mode on iOS" feature that we're exploring specifically for iOS to address those UX concerns. > 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. It's not only the browser that can intercept an App/Universal Link, the OS can do it as well. While some might think that's unlikely, we should remember that iOS has chosen to not allow browser engine choice, or the ability to access NFC, or allow side-loading, under the banner of security (while Android has allowed it without much fanfare or ill effects). > 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. Yes, but again, this only works for native apps and does not support web-based digital wallets. > 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 point here is that there are no standard ways to do this with SIOP, when there is ONE standard way to do this with CHAPI AND support both web and native wallets. SIOP does not address many of the mediation problems that have been raised over the years and continues to not be a source of solutions to that problem. > 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. ... and that led to terrible centralization in the social log in space. It eviscerated personal choice. While there are trade-offs to CHAPI, it addresses the need of same device invocation of a web or native wallet -- or to put it another way -- it finally enables personal choice in the digital wallet ecosystem, whether it be a web-based app or a native app. Other than CHAPI, there is no solution being fielded that meets all those requirements. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Sunday, 3 April 2022 18:58:39 UTC