Why expose IsLoggedIn state directly?

[johnwilander]

This issue was ported from WebKit/explainers#44.

What is the benefit to an application in knowing the value of isLoggedIn? My impression is that there's little to no benefit in having that data exposed - the real value here is in two separate pieces:

Setting state lifetimes based on some more interesting parameters. You have enumerated a possible set.
Telling the browser that it's okay (or advisable or desired) to destroy state - logout.
Should we instead separate those two and not expose the isLoggedIn state directly?

[johnwilander]

I'm not sure I understand this issue fully. Is this just about expiring/deleting website data based on the IsLoggedIn signal or lack of it? Because other uses of IsLoggedIn state are mentioned in the explainer. Or is it about not offering the isLoggedIn() API?

[samuelweiler]

I'm not sure I understand this issue fully. Is this just about expiring/deleting website data based on the IsLoggedIn signal or lack of it? Because other uses of IsLoggedIn state are mentioned in the explainer. Or is it about not offering the isLoggedIn() API?

The topic of "what is this for" came up - at some length - in today's CG call.

I'm saying "I understand the two uses of this are X and Y" - if you think there are others in the explainer, perhaps try to extract them to make them more clear?

Further, I'm suggesting

1. that a "you may/should destroy state now" signal seems more directly on-point for one of the use cases I understand this is solving.
2. the other use case doesn't need this signaling.

[johnwilander]

This was discussed on today's W3C WebAppSec call. From the notes, lightly edited:

John W: There's a GitHub issue on this [this one!]. I think if it was just down to the managed authentication flows, we could make it work. Password manager, WebAuthn, that's good enough. But two other things:

1. The user need to be able to log out, store that state. There's not a good heuristic for this action [for instance, sites don't clear all their website data on logout]. It needs to be a distinct thing.
2. There are so many custom login flows. The site may be actively trying to break password managers or something might happen out-of-band with your phone to login, which is invisible to the browser. Better to just give the site the ability to make an assertion.

Sam W: Logout, I get. There's a good case for that kind of signal. The strange flows to support suggests that the problem of trusting the signal is hard, that the heuristics won't be good enough.

John W: Yes, this is hard. We might solve the hard cases with a prompt, or prominent UI in the browser that could help users understand and react. An example or a hard case: BankID in Sweden. The bank site shows a QR code that you scan with your phone where an auth flow in the BankID app magically moves you to a logged-in state in the browser. Also note: Banks have such short limits on state that they're not really the canonical case.

Does the above resolve this issue, Sam?

[samuelweiler]

No, it does not. (If only because I don't fully understand the minutes, which are surely somewhat mangled.). Would you indulge me and enumerate the additional use case (again)?