Amy: I looked at this - seems probably fine - they've identified a problem and made an effort to solve it.

Amy: my other thought with FedCM is that a lot of it is early - and we're spending time on small feature reviews...

Dan: if it's being put forward as a more privacy preserving alternative for federated sign-in and enjoys some level of multi stakeholder support , any way we could accelerate it through .. if we can add energy into that it's positive. One of the things people want to replace the use of 3p cookies for is federated ID - it would be nice if we can say they can use fedcm. In Chrome status it says firefox under consideration, and going to origin trial.. For this feature they have an indication of positive or non-negative feelings from mozilla but link to a github thread.. not to any standards positions. We could ask about that.

Dan: can't find a moz standards pos.

Peter: a little confused - it looks like the problem they are trying to solve is IDPs silently tracking users - solution is IDP telling browser - wouldn't it be a problem if the IDP is malicious?

Amy: Isn't it a malicious RP not malicious IDP?

Peter: in their pdf they say the problem is the "tracker" gets a credentialled request that allows them to track the user at the RP.. makes it sound like the "tracker" is the IDP. You're visiting an RP and they want to expose some UI that says go sign in with google or whoever and they don't want to show that if you're not logged into google. So the browser can make a request to google to check if you're logged in.. which lets google know you're visiting the RP. Stopping the RP from calling the IDP if the IDP says you're not logged in. In an example they show the "tracker" is an IDP

Dan: wnat to clarify the problem they're trying to solve, and how to mitigate against a malicious IDP

peter: IDP has to opt in to giving a mechanism it can't use to track you. I don't see why an IDP that wants to track you can't just opt out.

Amy: the fedcm people have made a PR to the login status API that is currently under review. Lots of multistakeholder discussion

Dan: login api doesn't look very active, lots of open issues. We haven't reviewed it. Would be useful to know more...

1. Our understanding is that this is designed to prevent an IDP from tracking users. However, the mechanism provided allows the IDP to optionally signal the signed in status of the user to the UA. Couldn't an IDP that wants to track users simply not send the signed-out signal and thus still get the silent requests?

2. Regarding multi-stakeholder support, we see from ChromeStatus that Firefox is listed as "under consideration" - however I don't actually see a Mozilla standards position on this - is there one? Is there a webkit standards position?

3. What is the general status of FedCM from an implementation stand-point? What is the multi-stakeholder story with FedCM right now and when do we expect to achieve "critical mass" for FedCM? This is especially relevant to the discussion on deprecation of third party cookies, as federated sign-in is often cited as a use case supported by third party cookies.

4. Small addition question - you've reference a PR against is-logged-in in your explainer - however the is-logged-in API itself seems to not be very active – and we haven't been asked to review it. Can you shed some light on the status of this API?

Ready to progress. We need to look at their responses.

Amy: they replied to Dan's questions...

Peter: it's been renamed to LoginStatus API and there's an open issue on privacy cg.. there's a pr about merging ipd sign in status to the api...

Amy: looks like they made some progress at tpac, but don't say what it is

Peter: inclination is to ask them for current status, exlpainer is 404 and things seem to be in flux. The privacy cg has an explainer in it now...

Amy: last update was 3 years ago that can't be it

Peter: Looks like is-logged-in is supposed to play with fedcm but doesnt' depend on it..

Amy: [leaves comment]

[Peter:] Amy and I looked at this and think we can close as satisfied, but wanted Dan's feedback since he posted a number of questions.

Amy: it's shipping, and they did change the name

Peter: sounds like it's moving in the direction of letting the browser manage all of this. Let's the IDPs tell the browser whether they're logged in or not. Doing it with a header ... would only apply during a direct interaction with the idp? They are putting this in a separate object which isn't in a namesapce, ties into DP conversation last week...

Amy: we could give them guideance if we have an opinion...

Peter: I'd prefer the extra namespacing... but they're only adding one method, which is an argument for putting it on the navigator. I could see this api expanding in future. NO way to query this logged in state. Which is good. My main concern is tying it into the privacy cg is logged in api. Can we just combine all of these things?

Amy: sounds like it has overtaken/superseded that API?

Peter: happy to close this? Can check with Dan

Amy: yep

Peter: We pinged Dan (as previously discussed); he's OK with us closing this.

Hi @cbiesinger, we discussed this on our call today; we're happy with the direction the work is going, so we're closing this review. Thanks for flying TAG.