Meeting minutes
<cbiesinger> Zakim: start meeting
<AramZS> https://
<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
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://
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://
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