06:44:56 <RRSAgent> RRSAgent has joined #login-status
06:45:00 <RRSAgent> logging to https://www.w3.org/2023/09/13-login-status-irc
06:45:00 <Ian> RRSAgent, do not leave
06:45:02 <Ian> RRSAgent, make logs public
06:45:04 <Ian> Meeting: The Login Status API
06:45:06 <Ian> Chair: Johann Hofmann, sam goto
06:45:08 <Ian> Agenda: https://github.com/w3c/tpac2023-breakouts/issues/61
06:45:10 <Ian> clear agenda
06:45:12 <Ian> agenda+ Pick a scribe
06:45:16 <Ian> agenda+ Reminders: code of conduct, health policies, recorded session policy
06:45:18 <Ian> agenda+ Goal of this session
06:45:20 <Ian> agenda+ Discussion
06:45:22 <Ian> agenda+ Next steps / where discussion continues
06:45:31 <Ian> Ian has left #login-status
07:13:14 <Ian> Ian has joined #login-status
07:13:32 <Ian> Ian has left #login-status
14:03:18 <RRSAgent> RRSAgent has joined #login-status
14:03:18 <RRSAgent> logging to https://www.w3.org/2023/09/13-login-status-irc
14:03:30 <AaronCoburn> AaronCoburn has joined #login-status
14:03:31 <kristina> kristina has joined #login-status
14:03:35 <cbiesinger> Zakim: start meeting
14:03:35 <benoit> benoit has joined #login-status
14:03:35 <kristina> present+
14:03:39 <AramZS> AramZS has joined #login-status
14:03:40 <AaronCoburn> present+
14:03:46 <benoit> present+
14:03:47 <wanderview> present+
14:03:53 <cbiesinger> present+
14:03:53 <AramZS> https://www.w3.org/2001/12/zakim-irc-bot.html
14:03:56 <SameerT> SameerT has joined #login-status
14:04:10 <cbiesinger> Zakim, start meeting
14:04:10 <Zakim> RRSAgent, make logs Public
14:04:12 <Zakim> please title this meeting ("meeting: ..."), cbiesinger
14:04:21 <cbiesinger> Zakim, start meeting: Login Status Breakout TPAC
14:04:21 <Zakim> I don't understand you, cbiesinger
14:04:25 <AramZS> present+
14:04:29 <cbiesinger> Zakim, meeting: Login Status API breakout
14:04:29 <Zakim> I don't understand 'meeting: Login Status API breakout', cbiesinger
14:04:34 <AramZS> Zakim meeting: Login Status API
14:04:58 <antosart> antosart has joined #login-status
14:05:04 <AramZS> Zakim, this is Login Status API breakout
14:05:04 <Zakim> got it, AramZS
14:05:04 <cbiesinger> Zakim: this is Login Status API
14:05:28 <AramZS> q?
14:05:31 <kristina> zakim, start the meeting
14:05:31 <Zakim> RRSAgent, make logs Public
14:05:33 <Zakim> please title this meeting ("meeting: ..."), kristina
14:05:44 <johannh_> present+
14:05:53 <tara> tara has joined #login-status
14:06:01 <AramZS> Zakim what meeting is this?
14:06:05 <npm> present+
14:06:18 <johannh_> Zakim, what meeting is this?
14:06:18 <Zakim> I don't understand your question, johannh_.
14:06:21 <tara> Present+
14:06:31 <AramZS> zakim, agenda?
14:06:31 <Zakim> I see 5 items remaining on the agenda:
14:06:33 <Zakim> 1. Pick a scribe [from Ian]
14:06:33 <Zakim> 2. Reminders: code of conduct, health policies, recorded session policy [from Ian]
14:06:33 <Zakim> 3. Goal of this session [from Ian]
14:06:34 <Zakim> 4. Discussion [from Ian]
14:06:34 <Zakim> 5. Next steps / where discussion continues [from Ian]
14:06:36 <cbiesinger> zakim, what conference is this?
14:06:36 <Zakim> I have been told this is Login Status API breakout
14:06:57 <cfredric> cfredric has joined #login-status
14:07:07 <cbiesinger> zakim, move to next agendum
14:07:07 <Zakim> agendum 1 -- Pick a scribe -- taken up [from Ian]
14:07:15 <cbiesinger> zakim, move to next agendum
14:07:15 <Zakim> agendum 1 was just opened, cbiesinger
14:07:18 <johannh_> goto: This is a follow-up to PCG meeting from yesterday, and a general thing we've been discussing for a while
14:07:30 <johannh_> Will skip most of the intro and jump into options directly
14:08:13 <johannh_> A bit of history: John and Melanie introduced this a while back for Safari use cases
14:08:13 <johannh_> Meanwhile in FedCM we developed something that looked like Login Status
14:08:13 <AramZS> zakim, close this agendum
14:08:13 <Zakim> agendum 1 closed
14:08:13 <Gerhard> Gerhard has joined #login-status
14:08:13 <Zakim> I see 4 items remaining on the agenda; the next one is
14:08:13 <Zakim> 2. Reminders: code of conduct, health policies, recorded session policy [from Ian]
14:08:22 <cbiesinger> Zakim, close this agendum
14:08:22 <Zakim> I do not know what agendum had been taken up, cbiesinger
14:08:28 <johannh_> We want something that looks like Login Status, have something running in production
14:08:31 <cbiesinger> Zakim: move to next agendum
14:08:41 <cbiesinger> Zakim, move to next agendum
14:08:41 <Zakim> agendum 2 -- Reminders: code of conduct, health policies, recorded session policy -- taken up [from Ian]
14:08:45 <johannh_> Q for this group is whether FedCM should use Login Status or do its own thing
14:08:53 <cbiesinger> Zakim, close this agendum
14:08:53 <Zakim> agendum 2 closed
14:08:54 <Zakim> I see 3 items remaining on the agenda; the next one is
14:08:54 <Zakim> 3. Goal of this session [from Ian]
14:09:01 <cbiesinger> Zakim, move to next agendum
14:09:01 <Zakim> agendum 3 -- Goal of this session -- taken up [from Ian]
14:09:04 <npm> slides: https://docs.google.com/presentation/d/1a0lgvnqOhNm6_M34ga0Qpo86j0i2hcAk1QK_SYdO5Bk/edit#slide=id.g27dda386c9e_0_588
14:09:18 <johannh_> 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
14:09:40 <johannh_> Use cases:
14:09:43 <AramZS> scribe+ johannh_
14:09:48 <Tim_Huang> Tim_Huang has joined #login-status
14:10:06 <johannh_> Safari wants to extend lifetime of site data storage with login status
14:10:10 <n8s> n8s has joined #login-status
14:10:21 <benvds> benvds has joined #login-status
14:10:31 <johannh_> Other plausible use case is SAA degrading more gracefully when logged out, similar to FedCM
14:11:14 <johannh_> Trust model is similar, will come up later
14:11:14 <johannh_> Other use cases, not actively working on:
14:11:14 <johannh_> Login Status indicator in browser UI, i.e. an avatar in the omnibox
14:11:50 <benvds> Can someone share the notes doc link here?
14:11:54 <johannh_> Storage that doesn't get cleared with site data but gets restored with login
14:12:02 <johannh_> benvds: I'm taking notes here
14:12:08 <cbiesinger> Zakim, what is the url
14:12:08 <Zakim> I don't understand 'what is the url', cbiesinger
14:12:38 <cbiesinger> rrsagent, bookmark
14:12:38 <RRSAgent> See https://www.w3.org/2023/09/13-login-status-irc#T14-12-38
14:13:01 <johannh_> Gerhard: I saw FedCM in the demo and it had an avatar
14:13:15 <yigu> yigu has joined #login-status
14:13:47 <johannh_> goto: Passkeys, password manager, etc. counts as logging in for Safari
14:14:07 <johannh_> Gerhard: So it's self-attested?
14:14:18 <johannh_> goto: For some use cases it has to be mediated
14:14:54 <johannh_> JohnW: Remember me isn't about user clearing, but about browser clearing automatically. It would keep the token. For 2FA etc.
14:15:30 <johannh_> 2 other use cases: Formalizing success step of auth, currently no way for the browser to know if that's successful
14:15:51 <johannh_> other is formalizing logout
14:16:38 <johannh_> goto: Architectural questions:
14:16:57 <johannh_> The way that Safari and FedCM want to use these are different
14:17:15 <johannh_> How do we design the API so that different browser can implement / use different parts of the API?
14:17:21 <johannh_> Where does Firefox stand on this?
14:17:32 <johannh_> Maybe some of the SAA related ideas?
14:17:50 <johannh_> BenV: We're interested in both senses, both seem pretty distinct but we're keeping our eye on them
14:18:02 <johannh_> goto: Does what we've said align with your thinking?
14:18:10 <johannh_> BenV: Would have to scroll back through the notes
14:18:39 <johannh_> 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?
14:19:13 <johannh_> goto: One of the options is to have an object parameter in the API that controls the assurance / trustworthiness level
14:19:24 <johannh_> All names TBD here
14:19:34 <johannh_> One param could be "browserMediated" as a boolean
14:19:35 <Gerhard> q+
14:19:41 <benoit_> benoit_ has joined #login-status
14:20:09 <johannh_> 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
14:20:41 <johannh_> The call on the bottom is trusted and could help John's storage use case, call on the top could be for FedCM/SAA
14:20:56 <AramZS> q?
14:21:08 <benoit> benoit has joined #login-status
14:21:14 <benvds> q+
14:21:16 <AramZS> ack Gehard
14:21:18 <n8s> q+
14:21:26 <AramZS> q- Gehard
14:21:47 <johannh_> 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
14:22:20 <johannh_> 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.
14:22:41 <johannh_> Just the site telling the browser about that state, if 2FA is important to that then it may make sense, otherwise not
14:22:47 <AramZS> sees Gerhard
14:22:56 <AramZS> q- Gerhard
14:23:36 <johannh_> Gerhard: Gets to a philosophical level about being able to reduce friction, just saying that there might be more detail her
14:23:36 <benvds> q+ achim
14:23:45 <johannh_> JohnW: The site made the decision, can store 2FA details in a cookie. This API is just about telling the browser
14:24:10 <johannh_> Gerhard: If I make a call to the browser about a login and include the 2FA detail, the browser might allow without some friction
14:24:30 <johannh_> Maybe make some APIs more forgiving
14:24:32 <benoit> q+
14:25:09 <johannh_> johannh_: So this is more about security?
14:25:09 <johannh_> Gerhard: About protecting the user better
14:25:09 <benoit> (re 2fa indication followup)
14:25:14 <johannh_> goto: Okay to have this as a possible future extension?
14:25:24 <johannh_> Gerhard: absolutely, just making suggestions
14:25:38 <benvds> q- achim
14:26:49 <johannh_> 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
14:26:49 <johannh_> Gerhard: Concur, keep it simple
14:26:49 <AramZS> ack benvds
14:27:21 <johannh_> benvds: Mozilla hat on
14:27:28 <johannh_> 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
14:27:53 <johannh_> Self-declared could be useful, but bikeshedding about naming becomes important, need to make sure it's not observable to sites
14:28:34 <npm> scribe+ npm
14:28:40 <npm> Johann: one of my concern is that we are adding something to the web platform which is not very useful.
14:28:47 <AramZS> johannh_: one of my concerns is we are adding something to the web platform
14:28:56 <npm> Goto: John has some non hypothetical use cases
14:29:18 <AramZS> q?
14:29:29 <npm> 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
14:29:51 <npm> BenV: Agree on using this signal like this
14:30:14 <npm> 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
14:30:14 <Gerhard_> Gerhard_ has joined #login-status
14:30:57 <npm> Ben Kelly: we currently already use signals. We prefer higher fidelity signals
14:31:23 <AramZS> ack n8s
14:31:46 <cbiesinger> q+
14:31:57 <npm> Nate: not well thought out Meta position. But I think its important to consider the different ways that login happens. Standardizing can be hard
14:32:25 <npm> ... same thing with logout. You might want to logout and save the session, or logout and clear site data
14:32:43 <npm> ... I think remember me can be interesting, especially with regards to account recovery.
14:33:35 <npm> 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
14:33:55 <npm> ... But this is only about telling the browser what is going on. This API will not hold your login tokens.
14:34:17 <npm> 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.
14:35:06 <AramZS> Interesting the idea of a login->logout being considered to stash their session essentially, until next login
14:35:07 <npm> 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
14:35:41 <johannh_> q+
14:35:49 <npm> Nate: in Facebook, we want to allow the user to log back in with one click
14:36:05 <npm> JohnW: if you are dishonest, browser UI might tell the user
14:36:19 <npm> Nate: what is the appropriate thing for the website to communicate to the browser in that case?
14:36:26 <npm> JohnW: Only thing so far is the remember me token
14:36:50 <AramZS> ack benoit
14:36:51 <npm> Nate: might be better to discuss on GitHub
14:37:45 <npm> 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
14:37:45 <Theo> Theo has joined #login-status
14:37:45 <Theo> q!
14:37:48 <Theo> I did
14:37:50 <Theo> pls halp
14:37:53 <Theo> pls
14:37:53 <AramZS> q+ Theo
14:37:56 <Theo> q+
14:37:59 <Theo> Thanks!
14:38:01 <npm> .. 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
14:38:29 <benvds> q+
14:38:42 <npm> 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
14:38:47 <AramZS> ack cbiesinger
14:38:55 <npm> ... but we are hoping to get some agreement on what an initial version would look like.
14:39:08 <npm> ... So we can ship something that does not end up being incompatible
14:39:29 <benoit_> benoit_ has joined #login-status
14:39:33 <npm> 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
14:39:43 <AramZS> q+ to ask if the goal of FedCM is to store login identification in some respect in this property/api?
14:39:47 <npm> ... 1. FedCM 2 extend storage 3 storage access API
14:40:01 <cbiesinger>  AramZS -- no, for various reasons
14:40:07 <AramZS> ack johannh_
14:40:10 <AramZS> q-
14:40:16 <npm> Johann: what is the requirement for extending storage? Is that browserMediated?
14:40:34 <npm> ... 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.
14:40:45 <npm> ... I would love that we write down a proposal
14:41:00 <npm> Goto: Chrome does not plan to support that. We throw if browserMediated=true
14:41:27 <npm> 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
14:42:05 <npm> Johann: theoretically, if we ship without a parameter with the default being false... if we add it later, that would not be backwards incompatible
14:42:44 <npm> JohnW: it could work. I just think we would give developers the impression of a super simple API and the intent was never that
14:42:47 <AramZS> q?
14:42:59 <npm> Johann: I don't have a super strong opinion on having it or not
14:43:23 <npm> Goto: is it a valid use for us to use login status as a self-declared value? This is a question for you, John
14:44:05 <npm> 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?
14:44:23 <npm> JohnW: you can even ask the user: are you logged in? And that would count as mediated
14:44:40 <npm> Johann: still seems like this flag is kind of unnecessary
14:44:41 <kaustubhag> kaustubhag has joined #login-status
14:44:56 <npm> Goto: we don't necessarily need to expose the browserMediated flag.
14:45:23 <npm> Aram: Is the defaulting an issue?
14:45:57 <npm> JohnW: I'm thinking about how the web progresses. The developers could never understand that something else was coming along.
14:46:15 <npm> ... We could make it clear to developers now that there is a difference
14:46:25 <npm> Aram: so is the blocker that we need browserMediated=true?
14:46:49 <npm> 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
14:47:04 <npm> Aram: if somebody uses webAuthn, would that be the key for browserMediated=true?
14:47:32 <npm> Goto: If Chrome exposes the browserMediated=true, we have to check. And we are not ready for that
14:47:51 <AramZS> q?
14:48:02 <npm> Goto: even if we shipped in 10 years, we would still not need the flag
14:48:43 <benvds> queue?
14:48:45 <npm> 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
14:49:11 <npm> JohnW: it is surprising to me that Chrome does not see the usefulness of the signal
14:49:19 <AramZS> I also am unclear on what the point of an unverifiable login event being sent to the browser tbh
14:50:16 <cbiesinger> AramZS -- tldr, fedcm basically uses it as a signal whether to show a dialog or not make a network request
14:50:16 <cbiesinger> AramZS -- more background at https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md
14:50:16 <npm> 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
14:50:36 <npm> JohnW: I'm find doing that. The only reason we are trying to rush this is the deadline.
14:50:46 <AramZS> But how can it be a viable signal for that with no controls? Why wouldn't I just pop this at random?
14:50:46 <AramZS> ack Theo
14:51:14 <cbiesinger> AramZS: because then users will just get a weird dialog [if an RP makes a fedcm request to your site]
14:51:54 <npm> 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
14:52:14 <npm> JohnW: that is not the definition. Users know little about the web. But something they know is that they can login
14:52:30 <npm> Theo: but that can be independent on whether the website can re-identify the user.
14:52:55 <npm> ... that is a tough position to put the user in.
14:53:31 <npm> JohnW: this is only the site informing the browser
14:53:31 <AramZS> cbiesinger the intent is to replace the `recordSignedIn` API?
14:53:31 <npm> Theo: seems like a confusing experience
14:53:35 <npm> JohnW: I think you are getting into the browser policy. Like if logged out, then clear the user data
14:53:39 <cbiesinger> AramZS basically yes because we don't want to end up with two very similar APIs
14:53:57 <npm> Theo: it will be tough to agree on these things if we don't have understanding of what it is to be logged in
14:55:06 <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.
14:55:06 <AramZS> q?
14:55:06 <npm> 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
14:55:07 <AramZS> ack benvds
14:55:09 <johannh_> q+
14:55:18 <cbiesinger> AramZS: many people logging in to google (or facebook, etc) do not use the credentials API
14:55:36 <npm> BenV: Sam, you say you will throw when browserMediated=true. Can't you just say you don't understand that parameter?
14:55:40 <npm> Goto: that would be fine as well
14:56:47 <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.
14:56:58 <AramZS> ack johannh_
14:56:58 <npm> 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
14:57:03 <cbiesinger> AramZS: happy to chat more after this sessin
14:57:31 <AramZS> def! Or just point me at a good starting point to read in cbiesinger - I gotta get back into FedCM anyway
14:57:45 <npm> Johann: I think from Chrome side, it does not seem the end of the world to have an empty parameter
14:57:48 <wanderview> q?
14:57:49 <AramZS> Gonna close the queue because we're running out of time. Last chance to get on
14:57:55 <wanderview> q+
14:57:57 <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
14:58:00 <npm> ... I doubt it is easy to assert that the user wants that
14:58:38 <npm> 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
14:58:54 <AramZS> cbiesinger yeah, looking at it now but it is not clear what it does exactly in practice
14:59:01 <npm> Johann: for me it works
14:59:03 <AramZS> q?
14:59:07 <AramZS> ack wanderview
14:59:14 <AramZS> please close the queue
14:59:29 <npm> 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
14:59:29 <AramZS> Zakim, close the queue
14:59:29 <Zakim> ok, AramZS, the speaker queue is closed
14:59:52 <npm> Goto: that would work for Chrome FedCM. BenV, what do you think?
14:59:57 <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
15:00:13 <npm> BenV: how long would it take to get rid of it?
15:00:23 <npm> Goto: whenever we introduce the new uses
15:00:45 <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
15:00:46 <AramZS> Ok, I see, the issue is a signal to mark time that's the desire here.
15:00:59 <npm> ... location presuposes it is going to be used by FedCM
15:01:05 <cbiesinger> AramZS: so we show a dialog that prompts the user to log in (and also mark the user as logged out for now)
15:01:16 <AramZS> That is making more sense. Ok.
15:01:16 <cbiesinger> we think this sufficiently discourages trackefs
15:01:19 <npm> JohnW: I think it would be super unfortunate to have two similar APIs, and for developers to have to call both.
15:01:40 <npm> Ben Kelly: does this matter to FedCM now? The half logout state
15:02:47 <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.
15:02:48 <npm> Goto: what was described to us would work either way. With the remember me thing, Facebook might be considered logged in still
15:03:19 <npm> Ben Kelly: I think perhaps we can have two APIs and over time people move to the general one because it is clearer
15:03:21 <cbiesinger> AramZS: it is a benefit that this irritates the user! that will make RPs remove IDPs/trackers that trigger this
15:03:23 <benvds> q?
15:03:43 <npm> JohnW: are you not worried Sam that there will be FedCM misuse, and you would like to use a trustworthy signal?
15:03:44 <cbiesinger> (and I mean there's a million ways to irritate the user already...)
15:03:58 <npm> Goto: the economics are built such that there is no incentive to lie.
15:04:18 <npm> JohnW: over time, people might forget that this is not a trustworthy signal and build things around that
15:04:27 <npm> Johann: naming might fix some of this
15:04:34 <npm> Goto: how do we go from here?
15:04:47 <AramZS> list attendees
15:05:01 <npm> Johann: seems safe to implement this without params. Unless later you wanted the parameter to be non-optional
15:05:07 <npm> Goto: perhaps asking John and Ben
15:05:21 <npm> JohnW: I prefer we go with the simplest Login Status API, and not have two different ones.
15:05:32 <cbiesinger> I think we all prefer not having two different ones
15:05:49 <npm> BenV: sounds fine, it is a shame that urgency in shipping is causing potential choices we would not make
15:06:01 <npm> Christian: we have been talking about this for a long time though
15:06:39 <npm> Nate: if we have one API to mean two different things, that might still not be the best for developers
15:06:47 <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
15:07:04 <npm> Goto: seems we are converging on navigator.setLoggedIn. Initially used in Chrome as non mediated, and later extended to a more trustworthy signal
15:07:10 <npm> JohnW: yea
15:07:12 <AramZS> rssagent create the minutes
15:07:12 <cbiesinger> logged or signed?
15:07:15 <benvds> nods
15:07:23 <benvds> * nods
15:07:33 <AramZS> rssagent, create the minutes
15:08:11 <cbiesinger> RRSAgent, make minutes
15:08:12 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/13-login-status-minutes.html cbiesinger
15:08:19 <cbiesinger> ??
15:08:25 <cbiesinger> thanks RRSAgent
15:08:30 <cbiesinger> Zakim: bye
15:08:34 <cbiesinger> Zakim, byte
15:08:35 <Zakim> I don't understand 'byte', cbiesinger
15:08:38 <cbiesinger> Zakim, bye
15:08:38 <Zakim> leaving.  As of this point the attendees have been kristina, AaronCoburn, benoit, wanderview, cbiesinger, AramZS, johannh_, npm, tara
15:08:38 <Zakim> Zakim has left #login-status
15:08:47 <AramZS> RSSAgent, draft minutes
15:08:47 <AramZS> lol well it worked for one of us
16:14:01 <benoit> benoit has joined #login-status
16:18:04 <benoit> benoit has joined #login-status
16:19:21 <benoit> benoit has joined #login-status
16:57:41 <AramZS> AramZS has joined #login-status
17:22:56 <AramZS> AramZS has joined #login-status
18:06:15 <benoit> benoit has joined #login-status
18:19:37 <benoit> benoit has joined #login-status
18:37:11 <benoit> benoit has joined #login-status
18:48:08 <benoit> benoit has joined #login-status
18:52:54 <benoit> benoit has joined #login-status
19:06:16 <benoit> benoit has joined #login-status
19:33:14 <benoit> benoit has joined #login-status
19:39:56 <benoit> benoit has joined #login-status
20:09:07 <benoit> benoit has joined #login-status
20:17:51 <benoit> benoit has joined #login-status
20:18:54 <benoit> benoit has joined #login-status
20:29:58 <benoit> benoit has joined #login-status
20:35:13 <benoit> benoit has joined #login-status
20:42:23 <benoit> benoit has joined #login-status
20:49:07 <benoit> benoit has joined #login-status
21:06:41 <benoit> benoit has joined #login-status
21:15:20 <benoit> benoit has joined #login-status