Support multi-login and multiple user profiles

[privacycg]

Support multi-login and multiple user profiles

[gffletch]

If there is both a unique-id and display name then the unique-id may not even need to be a "username" but could be any unique identifier the site wants to use to identify the user at the next login.

I'm also curious how sites should implement the "Account Chooser" UX and whether this proposal puts any limits on those implementations.

[johnwilander]

If there is both a unique-id and display name then the unique-id may not even need to be a "username" but could be any unique identifier the site wants to use to identify the user at the next login.

Right, we'd just have to name the parameters in a way that maximizes the chances of developers getting them right. 🙂

I'm also curious how sites should implement the "Account Chooser" UX and whether this proposal puts any limits on those implementations.

I don't see this proposal affecting or instructing websites how to implement account switching. Do you think it needs to? Sure, it would be nice to have browsers offer account switching which would require a defined way to switch state. That would likely have to be switching website data sessions completely. But what I'm thinking is that the site merely tells the browser which user is currently logged in and the browser accepts that as an account switch.

[gffletch]

In most cases today... if the browser is not currently logged in but has been in the past, when the browser visits the login service instead of being shown an username/password page, they are shown a page of all the identities that have logged in from that browser. This is usually stored in local storage on the fully qualified domain of the identity provider. As long as the local storage will persist across login/logout flows then existing behavior should work fine. Some identity providers use a persistent cookie for this data instead of local storage.

[johnwilander]

In most cases today... if the browser is not currently logged in but has been in the past, when the browser visits the login service instead of being shown an username/password page, they are shown a page of all the identities that have logged in from that browser. This is usually stored in local storage on the fully qualified domain of the identity provider. As long as the local storage will persist across login/logout flows then existing behavior should work fine. Some identity providers use a persistent cookie for this data instead of local storage.

The exact policies browsers might apply based on the IsLoggedIn signal is outside the scope of this proposal (although #15 will be discussed at the F2F). If a browser decides to delete or hide website data after N days of no logged in state, the list of previously used identities will not be there on page load after N days. That is the same thing as the user deleting website data or the user using an ephemeral session and restarting their browser.

[gffletch]

So, browsers that implement that behavior will cause the users of those browsers to have a more challenging login experience because it won't be possible for the IDP to distinguish between a browser the user has used in the past and a brand new one possibly driven by an attacker. So the IDP will likely require the user to pass multiple challenges to ensure it's the correct user even though they logged into the site say M days in the past.