Support "Remember me" functionality

[johnwilander]

This issue was ported from WebKit/explainers#38.

Many websites have an option to remember certain things, typically the username, even after the user logs out (whether explicitly or via timeout). If setLoggedOut immediately clears all first party state (does it? this isn't really explained in the explainer yet), then these features likely can't work. Do we need a provision for them?

[melanierichards]

A couple different topics to discuss under this umbrella:

The motivating use case for "remember me" functionality

…is something like a bank website. These might have very aggressive logout practices for the user's financial security, but want certain data on a longer term. For example, they might want to provide a smoother user experience on subsequent logins by remembering the device and not requiring additional trust signals like 2FA and CAPTCHA completion.

IsLoggedIn could potentially support this by taking a "remember me" parameter that is stored on the device after IsLoggedOut is called (but could be cleared by the user). Once the website next sets IsLoggedIn, the browser could pass along the "remember me" bit, and the website can bypass 2FA etc.

Is this a use case we should support?

Related, should IsLoggedIn support storage of username metadata even when other local data is cleared, for a true "remember me" user flow (e.g. website can prefill the username field in a login form)? User consent mechanisms for this?

Hiding vs clearing website data in logged out state

At a broader meta point, should it be possible to hide website data on logged out state, rather than completely clear it, such that data can be restored at the next logged-in state? Should we consider this within the scope of IsLoggedIn?

[gffletch]

Left this comment on another issue... but it's relevant here:)

Not sure this is the best place to leave this comment... but a key aspect of identity flows on the web is for the identity provider to write a cookie into the browser on the fully qualified IDP domain (e.g. login.idp.example) that identifies that George has logged in from this browser. Consider this a trust token to improve the experience when George comes back and wants to login again.

Consider the "untrusted" experience when you go to a new coffee shop, open your browser, clear all your cookies and try and log into Google. You will likely be asked for more than just your password because of the "untrusted" nature of the login.

From an identity perspective, it is super important to be able to persist the "trust" token across logins/logouts. It's unclear to me how this is managed with the isLoggedIn proposal.

[AramZS]

I would like some sort of isKnown state, outside of isLoggedIn. That would also be useful for handling use cases like metered paywalls.

[melanierichards]

Seems like Trust Tokens might be a better fit for some of these use cases, but we can discuss on the call shortly!

[AramZS]

I think Trust Tokens are still intended to handle users as in or out of a log in state no? The goal is to handle the state between "totally unknown to the site" and "logged in to the site"

[AramZS]

After the discussion on the meeting, I think my comment needs to be a separate issue or perhaps a separate proposal as it is interested in addressing a very different use case.

[michaelkleber]

The way web login works today, it very often results in some amount of cross-site information leakage — either due to giving out a global email address, ot due to a federated identity provider learning what site you visit and maybe giving the relying party access to some global information about you. (I acknowledge that this doesn't have to be the case, but it usually is today.)

Pushing sites to make people log in, when the sites actually only need to remember single-domain information about them, seems to me to push things the wrong direction.

I think there is merit to the browser asking "Do you really want this site to remember stuff about your previous visits?", and perhaps hiding old data, rather than deleting it, until such a hurdle is cleared. And maybe if a user is (or perhaps was) logged in, then we can presume we know the answer to that question is "Yes".

But the state "recognized while on this site, but not logged in" is valuable for sites, and I believe it's better for privacy than conflating the two.

[gffletch]

Whether a site chooses to require sign-in or not seems out of scope for the decision here. In federated identity cases (at least with protocols like OpenID Connect) the information shared between the IDP and the Relying Party (RP) is clearly exposed to the user and the user can choose not to login and therefore not share that information with the RP. Many site activities actively require a login (e.g. reading mail, leaving a comment on a news story, storing personal information at the relying party, etc).

Note that when it comes to user experience and security of the user's identity across the web, it is actually very helpful to "track" the user in a way that allows the identity provider (whether local to the RP or federated) to separate malicious attempts to login to an account from real attempts to login to the account. If there is no state, then every attempt must be considered as unknown and hence require additional challenges to get the user logged in. I don't think this is the web we want. I believe most users are perfectly comfortable from a privacy perspective letting the IDP know things about their devices and activity in exchange for improving the UX and increasing the security of the identity online. The key here is that this information should only be used for these purposes.

Finally, if the long-term goal it to keep federated identity providers from knowing which relying parties the user is visiting, integrating with the self-sovereign-identity flows and making the browser a valid wallet/agent on behalf of the user would solve that problem.