Add custom schemes alternative analysis #37
Conversation
custom-schemes.md
Outdated
| 5. What is the user experience on a desktop operating system? | ||
|
|
||
| - Most wallet applications exist only as mobile applications, and users are generally reluctant to install native applications on desktop operating systems. What fallback will flows relying on custom URL schemes provide for users of desktop operating systems? | ||
| - A browser-based API can potentially provide low-friction integration between a desktop browser and a wallet application running on a mobile phone. |
There was a problem hiding this comment.
... or a web-based wallet, which provide a more seamless experience in many use cases that don't require HSMs, device-lockdown, etc. #33 (comment)
I will also note that there are now governments pointing out the need/desire for web-based wallets/solutions: #33 (comment)
There was a problem hiding this comment.
Yes, definitely! So you suggest expanding this point (or adding an additional point) to ask about integration with web-based wallets? I know I need to dig into this more, but I haven't gone over the implications too much yet. Does the browser API offer similar advantages over, say, registerProtocolHandler working with web wallets in response to custom scheme navigations?
There was a problem hiding this comment.
Yes, definitely! So you suggest expanding this point (or adding an additional point) to ask about integration with web-based wallets?
Yes, please. A separate bullet point would probably be best, something along the lines of:
- A browser-based API can also potentially provide a low-friction integration between a desktop browser and a website that provides an in-browser wallet experience on the same device.
Does the browser API offer similar advantages over, say,
registerProtocolHandlerworking with web wallets in response to custom scheme navigations?
Yes. We've gone to great lengths in CHAPI to provide wallet selection between both native and web-based wallets in the same UX. Excluding native wallets, or excluding web-based wallets always resulted in gnashing of teeth among the wallet providers that were left out, and at the end of the day, when control is handed over to the wallets, the UX looks/feels very much the same (get consent for the sharing of certain data).
Another thing to consider is requiring/forcing someone to always switch devices between desktop and mobile when using the Web is a pretty annoying UX pattern. You do (arguably) want something like that for high assurance use cases. However, I expect always requiring mobile phone interaction to result in: "I'll do this later", or "Ugh, my phone is upstairs/downstairs/charging" usability issues when a web-based wallet is just as capable and a more convenient experience for most of the common interactions we expect to be associated with the Verifiable Credentials ecosystem (read: not high assurance use cases).
Also keep in mind that mobile devices aren't the only secure ways of signing information -- Web apps + external authenticators exist and should be taken into consideration. We perform all sorts of really high assurance use cases with that tooling (or less capable tooling) available to us today.
There was a problem hiding this comment.
A browser-based API can also potentially provide a low-friction integration between a desktop browser and a website that provides an in-browser wallet experience on the same device.
Added along with the existing bullet.
Yes. We've gone to great lengths in CHAPI to provide wallet selection between both native and web-based wallets in the same UX. Excluding native wallets, or excluding web-based wallets always resulted in gnashing of teeth among the wallet providers that were left out, and at the end of the day, when control is handed over to the wallets, the UX looks/feels very much the same (get consent for the sharing of certain data).
Thanks, filed #38 to track.
Also keep in mind that mobile devices aren't the only secure ways of signing information -- Web apps + external authenticators exist and should be taken into consideration. We perform all sorts of really high assurance use cases with that tooling (or less capable tooling) available to us today.
Yeah it's a good point. Since that would still need some wallet-defined UI I think that's probably just an extension of the web wallet case, right? A web wallet that happens to use some variant of WebAuthn (whether internal or external authenticator) to provide a strong device-bound assertion?
|
Note that this thread of discussion (from which more text may be potentially added to this PR) was auto-resolved because of a suggestion at the end of it: |
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Ah thank you! Unresolved. |
| 6. What are the privacy implications of a wallet accepting custom schemes? | ||
|
|
||
| - In general, Android works to keep the list of installed applications private from other applications. However, applications registering to handle custom URL schemes effectively make their package name visible to other applications. By registering to support custom URL schemes, a wallet application may be leaking PII (such as the user's likely citizenship status or state of residency) to any other application on the device. | ||
| - A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage. |
There was a problem hiding this comment.
Converting one of my comments into a suggestion here:
| - A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage. | |
| - A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage. | |
| - A browser API could potentially keep private (from the relying verifier or issuer) the specific wallet the user selects to complete a request. This may be impossible or challenging when using other mechanisms (e.g., a custom URL scheme that includes an invitation to use a protocol that requires a wallet to directly communicate with the relying verifier or issuer). |
There was a problem hiding this comment.
Yeah I was wondering about saying something like that, but I didn't see how it would be materially different. Both setups involve some arbitrary data transfer protocol from the wallet back to the verifier. That protocol could be designed to either rely on wallet keys (or other form of wallet identification) or not, right? Direct communication isn't, I don't think, any more or less identifiable (just like web servers can't necessarily identify a browser unless the browser advertises itself somehow either directly or indirectly via it's precise behavior).
There was a problem hiding this comment.
Yeah I was wondering about saying something like that, but I didn't see how it would be materially different. Both setups involve some arbitrary data transfer protocol from the wallet back to the verifier. That protocol could be designed to either rely on wallet keys (or other form of wallet identification) or not, right? Direct communication isn't, I don't think, any more or less identifiable (just like web servers can't necessarily identify a browser unless the browser advertises itself somehow either directly or indirectly via it's precise behavior).
Yeah, I think that's right, but I was thinking about this less from the perspective of different protocol designers that equally consider this privacy characteristic -- and more from the perspective of wallet providers that are looking to implement existing protocols on offer.
I think there's an advantage to say that a browser API could provide this sort of privacy "by default", simply because of the architectural pattern that places the browser as a mediator between the RP and the wallet. Other protocols on offer that lack this architecture, especially those that do not consider this sort of privacy in their design, may incidentally have elements that make it an active challenge to try to provide it.
Some of this has come up before with protocols that require direct communication from Web wallet backend services because RPs are not CORS-enabled, leading, perhaps, to more easily identifying the wallet services chosen by the user -- or more challenges to wallet providers to help avoid this. These kinds of concerns and challenges can potentially be avoided entirely by wallet providers based on a browser-as-mediator architecture.
But I take the point that other protocols can attempt to build in this sort of privacy as well if they want to.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
|
Thanks for all the input folks! I'm going to merge this now in preparation for our call tomorrow, but am happy to continue to land improvements for any further comments here. |
| 1. Can wallets reliably determine their invoker? | ||
|
|
||
| - Android and iOS offer no facility to determine the web origin which triggered a navigation to a custom URL scheme. | ||
| - This seems to increase the opportunity for attacks such as replay attacks, man-in-the-middle attacks and phishing. It also seems to limit the opportunity for abuse detection and prevention. |
There was a problem hiding this comment.
android and iOS might not allow it, but that's why protocols like OID4VP/18013-7 talk about client_id_schemes and verifier authentication which allows the wallet to reliably determine the invoker.
|
what is the merge policy? the PR got merged in 3 days - I had it on my todo list to review assuming I had more time than 3 days... |
Explainer-type documents are are the discretion of the author. We are using GitHub instead of Google Docs to keep everything together. |
|
Hey @Sakurann, sorry I missed your comment after the PR landed (darn github notification overload). The group continued to iterate on this based on additional feedback after it landed (eg. see #41 and #45). I'm happy to either review a PR of additional suggestions or put one up myself based on your comment here? |
We've had some requests to publicly expand on the concerns we have with the use of custom URL schemes for wallet invocation. @timcappalli and @marcoscaceres, does this match your understanding as well?
@Sakurann and @msporny does this seem accurate and fairly represented to you? Improvements are appreciated, you both are more of experts in this space than I am.