custom-schemes.md: additional concerns

[hober]

1. Add two additional points.
2. Use headings instead of numbers so that nesting is more straightforward.
3. Separate the conclusion from the list of items.

[RByers]

Thanks! Reformatting looks good, just suggest using bullets consistently.

[RByers]

+1

[RByers]

I think existing wallets work by establishing their own (UI-less) HTTPS connection to the verifier server. Then the website can be waiting on a fetch to the server which resolves when the UI should be updated to indicate the credential has been received. I'm not an expert though, perhaps @Sakurann or @msporny want to weigh in here?

Regardless, existing apps definitely work in this regard. Perhaps this should be framed as a developer ergonomics issue?

[msporny]

Well, for some definition of "definitely work". :) It is possible to end in a "successful state", but that ignores the UX challenges of what happens when things go wrong. In the best case (on a same-device flow), presuming that the protocol has some sort of "navigate to this URL when you're done" feature, you're left with a "dead tab" in the browser -- something that the individual will never go back to and have to clean up later.

One of the design goals of CHAPI was to not "break the flow" in the existing web page (and not to leave "dead tab"s around). This is also aligned w/ the design goals for Payment Request (and Payment Handler). That is, you want the browser API to always tell you when the interaction is done (success or failure) and return you to the exact place you were on the website that invoked the interaction in the first place. I expect FedCM has the same (ideal world) requirements.

There are at least three problems w/ invoking a native app or a web-app (using what's available today) in a separate window:

1. In a same-device flow, when the flow completes successfully, navigating back to the same tab/window that the individual was in (in the browser) is not possible. In the best case, you have to open a new tab/window, leaving "dead tab"s around.
2. In a same device-flow, the UX is not ideal -- popping windows up (because you need to be in first party mode in many cases, and sometimes you need to log in -- which pops up more windows if you are using an external IdP) can cause the user to feel as if something bad is happening - "User: WTF is going on here? This doesn't feel right *closes window, breaking the interaction*").
3. In a multi-device or same-device flow, the user is never navigated back to the originating page when there is an error or the interaction is canceled. They're left in the "invoked app" and have to manually switch back to their browser session, which gets no indication that things went wrong and therefore "hangs" for an unacceptably long time -- 5 minutes, 10 minutes... how long should a site give an individual to complete an out-of-band flow?

It's not just a developer ergonomics issue, it's a UX issue, both for same-device and multi-device flows.

[RByers]

In a same-device flow, when the flow completes successfully, navigating back to the same tab/window that the individual was in (in the browser) is not possible. In the best case, you have to open a new tab/window, leaving "dead tab"s around.

Definitely agree not having a way to navigate back to the browser app is a problem that we should add to this list.

I had assumed the "best case" wasn't that the wallet would open a new browser window (which browser?), but that it would send a message to a server which the existing web page was waiting on and the user would manually switch back to their last application and see it complete. But there are problems with that as well (eg. under memory pressure the browser may have been killed). So OK Tess's description makes more sense to me now. I'll merge it as-is.

The jarring UX of a full screen app switch is also a problem I can add to the list. I think I've already captured your "3".

[msporny]

the user would manually switch back to their last application and see it complete

This is a tall UX ask of the user. Some of the testing we performed showed some individuals not understanding what the next step in the process was... so, after sending the presentation, they just sat there looking at the wallet, not knowing what to do (because some of them thought they were still in the browser and others didn't know about the usage pattern where you complete something in an app and then switch back to a browser -- it's a rare usage pattern on mobile phones to bounce from browser->app->browser for the same logical flow).

Some were expecting wallet to tell them the next step, and in some cases, the wallet just said "transaction complete!" and then nothing. This could be mitigated by the wallet showing a UI telling them to switch back to their browser (but that feels like a UX failure). To get a consistent experience across all wallets for that UX flow, you'd have to get all wallets to implement that (hacky) UX hint. We've also found that in some cases, once the individual is in the wallet, the wallet software wants them to do other things and keep them there ("Get another coupon!" ... "Add a credit card!" ... "Wait, update your password!" ... "Turn on MFA!")

So yes:

1. Full-screen is jarring, a modal that allows the UX flow to be performed and then return the individual back to the page (with a concrete transaction result for the website to process) is better.
2. Giving the wallet some hint about where to navigate the user back to (if we don't do the modal thing above) might also be helpful.

We might consider something like the "peek" feature in Arc as the ideal UX pattern to follow here:

https://www.reddit.com/r/ArcBrowser/comments/113ui8u/peek_by_arc_the_best_tab_never_made/

[danielfett]

That's more of a problem of the website and ecosystems can take precautions against this (rules, checks for HTTPS redirections, HSTS, etc.).

[msporny]

Leaving security up to "ecosystems" tends to result in more security holes than we'd like to see. The mere fact that you can invoke an OID4VP flow via an HTTP website is a security issue, and no amount of lecturing web developers will prevent that from happening. A browser API would help guide developers towards only operating in HTTPS mode, universally, which is a good thing.

[RByers]

I'm OK with relying on the ecosystem but only if we're confident the incentives are aligned with the agency. I think it's issuers who have the most incentive for security and so they're going to want to certify wallets. Most wallets will probably want to ensure they're invoked securely (even if only to earn the trust of the credential issuers). But verifiers may not have as much incentive, they're more incentivized to make adoption as easy as possible. So if wallets can't impose security requirements on verifiers then I think we have a break in the accountability chain and should expect security for users to suffer. Having the platform in the middle seems to fix this because the platform is incentivized to earn the trust of wallets/issuers (otherwise they'll go around the platform API), and so will impose security constraints on verifiers which increase trust of the wallets and issuers.

[danielfett]

The leak happens only when the website learns whether the app was opened or not (or am I missing anything?). Therefore, having e.g., a user interaction before the wallet calls back to the website (via a backchannel) would help to reduce the impact of this privacy leak. (It cannot be exploited in large scale any longer.)

[msporny]

@danielfett see this thread for background on this statement: #37 (comment)

[RByers]

Yeah that's not the problem. It's that registering an intent filter on Android makes your Android package name discoverable by other Android apps (silently and at any time) which say they need to query the system for apps satisfying that intent filter.

[tantek]

+1 on the additions and headings.