The Login Status API

13 September 2023


AaronCoburn, AramZS, benoit, cbiesinger, johannh_, kristina, npm, tara, wanderview
Johann Hofmann, sam goto
johannh_, npm

Meeting minutes

<cbiesinger> Zakim: start meeting

<AramZS> https://www.w3.org/2001/12/zakim-irc-bot.html

<AramZS> Zakim meeting: Login Status API

<cbiesinger> Zakim: this is Login Status API

<AramZS> Zakim what meeting is this?

Pick a scribe

goto: This is a follow-up to PCG meeting from yesterday, and a general thing we've been discussing for a while

Will skip most of the intro and jump into options directly

A bit of history: John and Melanie introduced this a while back for Safari use cases

Meanwhile in FedCM we developed something that looked like Login Status

We want something that looks like Login Status, have something running in production

<cbiesinger> Zakim: move to next agendum

Reminders: code of conduct, health policies, recorded session policy

Q for this group is whether FedCM should use Login Status or do its own thing

Goal of this session

Slideset: https://docs.google.com/presentation/d/1a0lgvnqOhNm6_M34ga0Qpo86j0i2hcAk1QK_SYdO5Bk/edit#slide=id.g27dda386c9e_0_588

Want to reconcile both how Chrome / FedCM wants to use as well as other browser vendors, don't want to corner ourselves in designing this

Use cases:

Safari wants to extend lifetime of site data storage with login status

Other plausible use case is SAA degrading more gracefully when logged out, similar to FedCM

Trust model is similar, will come up later

Other use cases, not actively working on:

Login Status indicator in browser UI, i.e. an avatar in the omnibox

<benvds> Can someone share the notes doc link here?

Storage that doesn't get cleared with site data but gets restored with login

benvds: I'm taking notes here

Gerhard: I saw FedCM in the demo and it had an avatar

goto: Passkeys, password manager, etc. counts as logging in for Safari

Gerhard: So it's self-attested?

goto: For some use cases it has to be mediated

JohnW: Remember me isn't about user clearing, but about browser clearing automatically. It would keep the token. For 2FA etc.

2 other use cases: Formalizing success step of auth, currently no way for the browser to know if that's successful

other is formalizing logout

goto: Architectural questions:

The way that Safari and FedCM want to use these are different

How do we design the API so that different browser can implement / use different parts of the API?

Where does Firefox stand on this?

Maybe some of the SAA related ideas?

BenV: We're interested in both senses, both seem pretty distinct but we're keeping our eye on them

goto: Does what we've said align with your thinking?

BenV: Would have to scroll back through the notes

goto: A couple of things how the API could be used in the future, how can we design the API to leave the door open to those?

goto: One of the options is to have an object parameter in the API that controls the assurance / trustworthiness level

All names TBD here

One param could be "browserMediated" as a boolean

If false, website says the status is self-asserted, vs. if true then the browser checks if some passkey or so was previously mediated to assert it

The call on the bottom is trusted and could help John's storage use case, call on the top could be for FedCM/SAA

Gerhard: Comment: When you do a login, there's a first-level login and there's a 2nd factor auth, might be useful even in the self-attested case to have a field for the level of attestation

John: Came up yesterday, important to say that the login status api doesn't replace the site's own knowledge of how the user is logged in, needs to be managed by the site.

Just the site telling the browser about that state, if 2FA is important to that then it may make sense, otherwise not

<AramZS> sees Gerhard

Gerhard: Gets to a philosophical level about being able to reduce friction, just saying that there might be more detail her

JohnW: The site made the decision, can store 2FA details in a cookie. This API is just about telling the browser

Gerhard: If I make a call to the browser about a login and include the 2FA detail, the browser might allow without some friction

Maybe make some APIs more forgiving

johannh_: So this is more about security?

Gerhard: About protecting the user better

<benoit> (re 2fa indication followup)

goto: Okay to have this as a possible future extension?

Gerhard: absolutely, just making suggestions

Achim Schlosser: Also think we should keep it narrow for now, in FedCM syncing server state with browser state became very complicated, there's often some kind of real time aspect to it

Gerhard: Concur, keep it simple

benvds: Mozilla hat on

The mediated version that John is talking about makes a lot of sense, can still bikeshed on the names later, which particular signals before or when it's pending, can go into the details of that later

Self-declared could be useful, but bikeshedding about naming becomes important, need to make sure it's not observable to sites

Johann: one of my concern is that we are adding something to the web platform which is not very useful.

<AramZS> johannh_: one of my concerns is we are adding something to the web platform

Goto: John has some non hypothetical use cases

John: We've seen a browser mediated login, that is a strong signal that the user has a long term relationship with this website, so we should retain stuff longer

BenV: Agree on using this signal like this

Johann: Are we sure that logged in sites are never tracking users as third parties? Popular media sites could become bounce trackers to follow you on the web

Ben Kelly: we currently already use signals. We prefer higher fidelity signals

Nate: not well thought out Meta position. But I think its important to consider the different ways that login happens. Standardizing can be hard
… same thing with logout. You might want to logout and save the session, or logout and clear site data
… I think remember me can be interesting, especially with regards to account recovery.

JohnW: this was proposed by me years ago, and we had long discussions. All of the things mentioned have been discussed, and are captured in issues. You could have multiple usernames and switch between them
… But this is only about telling the browser what is going on. This API will not hold your login tokens.

Nate: but for the storage example, if the user wants to logout, they want to be able to go back to their account with a single click.

<AramZS> Interesting the idea of a login->logout being considered to stash their session essentially, until next login

JohnW: the remember me token was a result of these discussions where some websites aggresively log you out, but still want to have an easy path to relogin

Nate: in Facebook, we want to allow the user to log back in with one click

JohnW: if you are dishonest, browser UI might tell the user

Nate: what is the appropriate thing for the website to communicate to the browser in that case?

JohnW: Only thing so far is the remember me token

Nate: might be better to discuss on GitHub

Benoit: comment on multi factor authentication. It is sometimes useful for the browser to know the types of things the user has to interact with

<Theo> q!

<Theo> I did

<Theo> pls halp

<Theo> pls

<Theo> Thanks!

Benoit: For example banks with electronic payments: user has to enter some data. If browser is aware last time 2FA was given, it can prompt in advance, and attach to next request

Christian: We would like to ship this soon in FedCM. For us, the definition is "will the accounts list return accounts". There has been discussion on longer term extensions
… but we are hoping to get some agreement on what an initial version would look like.
… So we can ship something that does not end up being incompatible

Goto: there is a lot that can be done with this API, but it may be years in the making. I suggest we focus on the things we are trying to do in the foreseeable future
… 1. FedCM 2 extend storage 3 storage access API

<cbiesinger> AramZS -- no, for various reasons

Johann: what is the requirement for extending storage? Is that browserMediated?
… If we had a perfect signal, we would have tons of applications for this. But I don't see a proposal on how to get there right now.
… I would love that we write down a proposal

Goto: Chrome does not plan to support that. We throw if browserMediated=true

JohnW: If we do not add the flag, we will have developers adopting this, and then we will tell them there are two trust levels

Johann: theoretically, if we ship without a parameter with the default being false... if we add it later, that would not be backwards incompatible

JohnW: it could work. I just think we would give developers the impression of a super simple API and the intent was never that

Johann: I don't have a super strong opinion on having it or not

Goto: is it a valid use for us to use login status as a self-declared value? This is a question for you, John

JohnW: yea, we want to make it useful for both use cases. Mediated does not have to be passkeys, password manager. We could try to figure out: was there a password field where user entered?

JohnW: you can even ask the user: are you logged in? And that would count as mediated

Johann: still seems like this flag is kind of unnecessary

Goto: we don't necessarily need to expose the browserMediated flag.

Aram: Is the defaulting an issue?

JohnW: I'm thinking about how the web progresses. The developers could never understand that something else was coming along.
… We could make it clear to developers now that there is a difference

Aram: so is the blocker that we need browserMediated=true?

JohnW: ideally for me, we would communicate this now so that sites use this truthfully. It would still not matter for FedCM but they would call the API in the right way

Aram: if somebody uses webAuthn, would that be the key for browserMediated=true?

Goto: If Chrome exposes the browserMediated=true, we have to check. And we are not ready for that

Goto: even if we shipped in 10 years, we would still not need the flag

Goto: we have browserMediated=false as default. If true is right, we reserve the right to throw. In future, we can agree on what it means to check for mediation

JohnW: it is surprising to me that Chrome does not see the usefulness of the signal

<AramZS> I also am unclear on what the point of an unverifiable login event being sent to the browser tbh

<cbiesinger> AramZS -- tldr, fedcm basically uses it as a signal whether to show a dialog or not make a network request

<cbiesinger> AramZS -- more background at https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md

Johann: I think I haven't seen a viable proposal that this can exist. LoginStatus attempts to list a few ways but no exact rules

JohnW: I'm find doing that. The only reason we are trying to rush this is the deadline.

<AramZS> But how can it be a viable signal for that with no controls? Why wouldn't I just pop this at random?

<cbiesinger> AramZS: because then users will just get a weird dialog [if an RP makes a fedcm request to your site]

Theo: It would be interesting to try to define what we mean by logged in. Does this mean: can this website re-identify you the next time that you visit? This is fingerprinting

JohnW: that is not the definition. Users know little about the web. But something they know is that they can login

Theo: but that can be independent on whether the website can re-identify the user.
… that is a tough position to put the user in.

JohnW: this is only the site informing the browser

<AramZS> cbiesinger the intent is to replace the `recordSignedIn` API?

Theo: seems like a confusing experience

JohnW: I think you are getting into the browser policy. Like if logged out, then clear the user data

<cbiesinger> AramZS basically yes because we don't want to end up with two very similar APIs

Theo: it will be tough to agree on these things if we don't have understanding of what it is to be logged in

<AramZS> Ok, yeah, I still am unclear of the usefulness of this vs some sort of interaction with the credentials api cbiesinger but I am behind on FedCM stuff and need to catch up so I am prob missing stuff.

JohnW: I did mention the stopgap where the user would be consulted. But in other cases, the user agent e.g. saw passkey and will trust this

<cbiesinger> AramZS: many people logging in to google (or facebook, etc) do not use the credentials API

BenV: Sam, you say you will throw when browserMediated=true. Can't you just say you don't understand that parameter?

Goto: that would be fine as well

<AramZS> Popping a random UI that isn't guaranteed to do anything seems like a great way to establish a venue to irritate a user but I'm feeling like I'm really missing something here cbiesinger and I guess I'll have to review more deeply to understand the full flow here.

BenV: if there is interest among browsers for a trustworthy signal for this, I do think that changing from the untrusted to "oh now there are two versions" seems a bit weird

<cbiesinger> AramZS: happy to chat more after this sessin

<AramZS> def! Or just point me at a good starting point to read in cbiesinger - I gotta get back into FedCM anyway

Johann: I think from Chrome side, it does not seem the end of the world to have an empty parameter

<AramZS> Gonna close the queue because we're running out of time. Last chance to get on

<cbiesinger> AramZS: have you read https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md ? that's probably the best introduction for now

Johann: I doubt it is easy to assert that the user wants that

Goto: John, would default being false satisfy you? We would return some failure when it is set to true. In Safari, you might error when it is false. Firefox can pick their choices

<AramZS> cbiesinger yeah, looking at it now but it is not clear what it does exactly in practice

Johann: for me it works

<AramZS> please close the queue

Ben Kelly: I just wonder: there is a lot of discussions about basic definitions. Perhaps the safer path is to use your own FedCM method for now

Goto: that would work for Chrome FedCM. BenV, what do you think?

<cbiesinger> AramZS: in short, we want to condition fedcm on the IDP having called recordLogin. we want to prevent a silent timing attack, so then we make sure that every fedcm call (that has sent as credentialed request) will show some kind of dialog

BenV: how long would it take to get rid of it?

Goto: whenever we introduce the new uses

<cbiesinger> AramZS: if we get no account list even though the IDP has previously called recordLogin, this is either a tracker or the sesion expired server-side

<AramZS> Ok, I see, the issue is a signal to mark time that's the desire here.

Goto: location presuposes it is going to be used by FedCM

<cbiesinger> AramZS: so we show a dialog that prompts the user to log in (and also mark the user as logged out for now)

<AramZS> That is making more sense. Ok.

<cbiesinger> we think this sufficiently discourages trackefs

JohnW: I think it would be super unfortunate to have two similar APIs, and for developers to have to call both.

Ben Kelly: does this matter to FedCM now? The half logout state

<AramZS> I'm still not entirely sure that's desirable, b/c it could theoretically still be used to irritate or push the user to login in a bad UX for the user.

Goto: what was described to us would work either way. With the remember me thing, Facebook might be considered logged in still

Ben Kelly: I think perhaps we can have two APIs and over time people move to the general one because it is clearer

<cbiesinger> AramZS: it is a benefit that this irritates the user! that will make RPs remove IDPs/trackers that trigger this

JohnW: are you not worried Sam that there will be FedCM misuse, and you would like to use a trustworthy signal?

<cbiesinger> (and I mean there's a million ways to irritate the user already...)

Goto: the economics are built such that there is no incentive to lie.

JohnW: over time, people might forget that this is not a trustworthy signal and build things around that

Johann: naming might fix some of this

Goto: how do we go from here?

<AramZS> list attendees

Johann: seems safe to implement this without params. Unless later you wanted the parameter to be non-optional

Goto: perhaps asking John and Ben

JohnW: I prefer we go with the simplest Login Status API, and not have two different ones.

<cbiesinger> I think we all prefer not having two different ones

BenV: sounds fine, it is a shame that urgency in shipping is causing potential choices we would not make

Christian: we have been talking about this for a long time though

Nate: if we have one API to mean two different things, that might still not be the best for developers

<AramZS> Huh... I'm not sure that will actually happen in reality. A lot of things go on with sites that is out of their control as js triggers js

Goto: seems we are converging on navigator.setLoggedIn. Initially used in Chrome as non mediated, and later extended to a more trustworthy signal

JohnW: yea

<AramZS> rssagent create the minutes

<cbiesinger> logged or signed?

<benvds> nods

<benvds> * nods

<AramZS> rssagent, create the minutes

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).


Maybe present: Aram, BenV, benvds, Christian, Gerhard, goto, Johann, John, JohnW, Nate, Theo

All speakers: Aram, Benoit, BenV, benvds, Christian, Gerhard, goto, Johann, johannh_, John, JohnW, Nate, Theo

Active on IRC: AaronCoburn, AramZS, benoit, benvds, cbiesinger, Gerhard, Ian, johannh_, kristina, n8s, npm, tara, Theo, wanderview