Tess: login status api integration into fedcm. Login status api is from apple. Need to see if it's..

Hadley: no status from safari..

Tess: Sam from google reached out recently about integrating login status api into fedcm. I don't know if anyone has had a chance to look at it yet. The use case should be solved. Devil in the details.

Hadley: having read the userinfo api I'm concerned about .. the general idea is that once you've already signed in it wants to be able to prompt you to continue on that site with what you already sign in with because the browser is going to remember..

...

... Looking at invisible tracking problem - says they're mitigating but can't see anything that stops a site using it

Peter: talking about the login button as a cross origin iframe controlled by the IDP but depends on 3p cookies.. so instead of having to rely on a cookie you can ask the browser directly. RP doesn't necessarily know that you've logged in.. and doesn't know who you are until you've logged in. But IDP knows you're visiting this RP even before you log in.

Hadley: that's the invisible tracking attack

PeteR: they're saying they mitigate by making it visible. But nothing saying it has to be visible. Ask for the information andthen just not present it to the user.

Hadley: true. Or user is supposed to click continue in order to proceed?

Peter: yeah but if the IDP is just rendering an iframe they could render anything they want. It's still going to track you, you've got all your user info, name, avatar, and not present it. Is there something in the browser to surface this information, or are we relying on the IDP to surface this information?

Hadley: looking at the fedcm explainer it looks like we're relying on the idp to issue a token that goes to the user agent. The ua has to check that

Peter: browser gets the token when you're logged in?

Hadley: so not whether you've been logged in previously?

Peter: I Think the browser only has the token once you have logged in. So in this case you don't have a token yet. I guess you're still logged into the idp but not logged into the rp

Amy: there's a lot of detail in their S&P questionnaire. I'm inclined to say these additions are fine.

Peter: they're aware of the tracking problem and they think they're mitigating it but I'm not sure if their mitigation is as effective as they think it is. Maybe I'm missing a detail.

Amy: worth leaving that comment to ask for clarification

Peter: reading that.. the idp already has this information.. if they fetch the information but don't surface it they haven't found anything they don't already know. Still seems weird.

Hadley: that's how I understand it. Fundamentally the RP should know that you've already been able to log in there..? although I guess it would know that through tracking which is not ideal

Peter: are theyt alking about the idp and the rp have collaborated out of band to track? Feel like I'm missing something [will ask the question]

Peter: fine by me.

Peter: we talked about FedCM... some possibility of information leakage... and if the idp calls the api from an iframe and has to already know the id of the rp... how do they get that?

Peter: we need to find more info from them... i need to get better understanding...

Hadley: agree - also the both shipped in june in Chrome...

Dan: Shipping 116 - positive signals from Firefox.

Tess: nobody else shipping though...

Dan: should we get them on a call?

Peter: I will do some more research on it... will leave some feedback on the issue.

PR 290 on design principles

Tess: we're trying to talk about the failure scenario... Been working on this for a while since breakout with Alice in Iceland. Tension between implementability and interop. Presumption of this text is "plan A failed" - weren't able to come up with a solution that worked for everyhone. Describing the alternatives and their downsides... So it's weird. We've had tons of feedback. We've addressed the feedback...

Dan: I think we should merge.

Peter: I'm ok with merging proviso one minor typo in markup

merged

Peter: three different features.. context bit looks fine to me. Gives me pause.. if I sign in from the IpD and sign out it still wants retain my identity, so I can do a 'sign in as..'. Not good for shared computers. Next person on the machine gets to see who I was.

Amy: yeah it looks like if the user grants permission for Rp-IDP communication, then signs in on a public computer, it would still apply that consent to remember them as a returning user..

Peter: other than that, not seeing any obvious issues

Amy: login hint doesn't seem to introduce any specific privacy issues

Peter: [leaves comment]

Amy: they've replied that the thing we were worried about with UserInfo is not actually a thing that happens

Peter: their answer conflicts with my understanding of what they were asking for

Amy: what is it querying? if you log out and walk away and the next person sits down..

Peter: you only get continue as if you're already signed into the IdP.. maybe that's what we were misunderstanding

Amy: so you have to remember to sign out of your IdP as well as your RP

Peter: what's the log out story.. if I click on log out on pinterest, did I also log out of google? Is that clear? When I log into google now, I immediately log out, then next time I go to log in it says 'continue with..' so they are storing a cookie

Amy: so that's what they're replacing?

Peter: if I'm signed out of the idp does the idp really have no knowledge ..?

Amy: with the google xample it would be a first party cookie, this is replacing third party cookie

Peter: it's only reflecting the fact that you're signed in, not that the idp might not know who you are when you're not signed in.. that bears out in their flow chart

Amy: very slight security problem in that it makes it easier for a malicious next user to sign into an RP if you forgot to sign out of your idp, whereas they couldn't before

Peter: this is a general problem with fedcm... need to make it clear when you sign out of an RP are you also signing out of the IdP or not. Single sign out - it's a problem with lots of single sign on

Amy: where is the best place to ask about this... An issue on their repo?

Peter: is it more explicit in their spec? Not seeing much. CG report about sign out flow. Not seeing anything about it in explainers. asks in issue

Amy: and propose close? This is sort of orthogonal

Peter: yes, we were fine with their original question, this is higher level

Peter: I think we were OK closing this on the basis that it's no more harmful - though I have concerns about clarity to the user, when logging into/out of an IDP, exactly what they're logging into/out of. They will get logged into multiple sites, and may not log out of the IDP. This is a big risk. This issue brought it up, but it's a general concern.

Matthew: :-O

Peter: Some providers don't support single sign-out - lots of users don't realise they're not fully logged out.

Matthew: Whom should we go to about fixing this?

Peter: it's a FedCM issue, but also about user intent - on a private machine, users may not want to fully sign out each time, but it needs to be made clear to them what they're doing, and the consequences.

Matthew: Should we file a tracking issue (on us or elsewhere)?

Peter: checks for an existing similar issue in FedCM repo

Peter: We were wondering if all of this UI/UX should be handled by the UA instead. This is something that could be solved in that scenario, in a standard way, with the UA as a situational observer. Prior feedback on this was that it's not on the roadmap.

Matthew: That sound good! How can we track it? Is there an issue already filed on that?

Matthew: takes action to figure out how to track this

Peter: With respect to this issue, I think we can close it, but would want Amy's buy-in on that.

Peter: adds propose close

Review on pause until Amy gets back.