Cater for existing logins, a.k.a. upgrade to IsLoggedIn

[johnwilander]

Once browsers ship this API, there will be a set of existing login sessions. Ideally those websites shouldn't have to re-authenticate the user to get the IsLoggedIn bit set. There needs to be a path to "upgrade to IsLoggedIn."

[johnwilander]

I promised to update this issue at today's call with the "menu" of options we have considered for the upgrade to IsLoggedIn case:

• A grace period, such as the first year of API availability. This would mean relaxed rules around how a website can claim IsLoggedIn status for an adoption time and could be combined with all the other options.
• URL bar pill. An IsLoggedIn status indicator in the URL bar or similar. It would light up the first time the user logs in and then remain but unlit when they user logs out.
• A prompt. This would be for sites that already have an active logged in state that call the API to set IsLoggedIn. The browser could ask the user something like "This website thinks you're logged in. Are you? Yes/No." This option is the likely solution to supporting non-mediated login flows so it would effectively collapse those two issues.
• 7 days rolling always OK. We could have a parameter with which websites say how long they will consider the user logged in unless they explicitly log out or clear website data. We could say that if that parameter is 7 days or less, we always accept the website's claim that the user is logged in. Part of the thinking here is that the browser would not delete website data for the site in less than 7 days anyway. But there are other things that may be gated on IsLoggedIn status which makes this option problematic.
• Heuristic. The browser could check for saved credentials or WebAuthn state for a site that claims existing logged in state and use it as a heuristic to allow the site to set IsLoggedIn. The browser could even have a heuristic based on the existence or state of specific cookies it knows represents logged in state for certain websites. The cookie heuristic would have a challenge around user name since it may not be readily available in website data.
• Require re-authentication. This is the conservative option. Websites that want to set IsLoggedIn need to take the user through a login flow. This would be the equivalent of not supporting non-mediated login flows for the purposes of IsLoggedIn.

[ajknox]

I believe it's very early to devote much energy to migration strategy, as it's still not clear the proposal itself solves an important problem adequately.

As far as I can tell, none of the options listed so far require specific action on behalf of web developers and therefore probably don't need to be standardized - it's not a collective action problem, there is no tragedy of the commons. In the event that everyone implements, if Safari gave a user prompt, Chrome gave a grace period, and Firefox forced a re-log, I don't see how the lack of standardization itself creates a harm. Users and developers may prefer different schemes, but it looks to me like each browser could just implement the scheme they prefer, and compete/differentiate themselves on ease vs. utility.

If there is a specific migration strategy that does require special action by the sites to qualify above and beyond sending isLoggedIn flags in the first place, that could show a collective action problem and warrant more discussion.