Should FedCM use the Login Status API?

[samuelgoto]

TL;DR; this is a proposal to use navigator.recordLogin() (rather than IdentityProvider.recordLogin()) to help raise the FedCM privacy properties

FedCM has been working on the IdP Sign-in Status API (explainer and PR), which we believe to be a sub/narrow case of the more general Login Status API.

Over the course of its development, we heard from Mozilla that they'd like to see the IdP Sign-in Status API reconciled with the Login Status API, which I think is something that Safari would be generally supportive of based on what we discussed at TPAC2022.

Currently, the IdP Sign-in Status API is exposed as IdentityProvider.recordLogin() (and using recordLogin() was a deliberate choice to get us closer to the Login Status API), and I think Mozilla is suggesting that we use navigator.recordLogin() (so that it is effectively reconciled with the Login Status API as the same API).

The suggestion makes sense to me overall.

So, effectively, the proposal is to use navigator.recordLogin() instead of IdentityProvider.recordLogin() and to figure out how the specs refer to each other.

How does this sound, directionally speaking, to you?

PS A few (solvable, IMO) wrinkles:

• This is a proposal to use the Login Status API in this very strict and narrow way for FedCM specifically (with well defined semantics/consequences in the FedCM flow specifically), not the more broad proposal that was made in the explainer (with undefined semantics/consequences). We would need to work together to be more precise in the explainer as well as spec text (on the specific parts that are going be effectively used by multiple implementations).
• The IdP Sign-in Status API has only implications / consequences to FedCM, so we are worried about any random website calling it and writing something to browser storage that is not meaningful. So, we'd like to add some indication, e.g. navigator.recordLogin({idp: true}) that indicates that this is an user logging-in to an identity provider rather than any arbitrary website.
• We heard from developers that a lot of their login systems use HTTP 302s rather than JS, so we also introduced a header called "IdP-SignIn-Status: action=signin" and "IdP-SignIn-Status: action=signout-all" which is intended to be equivalent to the JS API. We would also reframe it to be something like "SignIn-Status: action=signin, idp=true" so that it can be used by regular websites too in the future.
• The signature of recordLogin() isn't exactly what we need at the moment (e.g. it takes a username), so we'd likely need to narrow it down.
• We called the logout function recordLogoutAll(), to handle cases where multiple-accounts are used.

[johannhof]

To sum up some of my thoughts from the meeting (and I think this aligned with what @samuelgoto thinks as well):

It sounds like an interesting opportunity to have the {Sign-In, Login}-Status API available outside of FedCM, which is why I'm in favor of this proposal. I'm still personally interested in solving the original problem of this API (a way for Storage Access to know who to prompt in the first place).

However, I agree with Sam in that I'm concerned about the current state of this proposal and don't think it's entirely possible for e.g. Google Chrome to have a clear position on this API at the moment. The reason is that the explainer outlines a lot of potential goals and possibilities for the API that could prove challenging for privacy, developer and user experience when integrated with FedCM, e.g. the strong connection to browser-granted privileges to logged in sites and the ability for sites to directly query login status in a 3P context.

None of that is insurmountable, so it would be good if we could refactor the proposal based on a modern vision of concrete implementation as part of FedCM (and potentially SAA) and lay out some ground rules about what is and isn't possible.

My idea would be an API that makes it easy to set the "logged in" bit in various situations but make it impossible for a website to read its state directly. Instead, it can be used as a tool for 3Ps to privately alter the user experience on sites without learning about the user identity or logged-in state. This seems much more feasible than the opposite approach of attaching powerful capabilities and side effects (some of which are only tangentially connected to login) to login state and trying very hard to counter the inevitable abuse attempts that would follow it.

cc @johnwilander @annevk

[annevk]

I discussed this with colleagues and overall this seems like a reasonable way forward.

cc @pascoej

[samuelgoto]

I discussed this with colleagues and overall this seems like a reasonable way forward.

Ok, seems like we are more or less in directional agreement.

I forked this repo and wrote down here how I think this could play one is slightly more concrete terms, and I send a PR to merge into this repo.

If this PR is accepted, I can work with you all to write more precise spec text, but wanted to do that only after we get some overall consensus on how to go about things.

@annevk @johannhof @johnwilander @bvandersloot-mozilla, WDYT?

[samuelgoto]

Friendly ping?

Just to give some context to make sure we are transparent about our timelines: we sent our Intent to Experiment in June and we are planning to run origin trials until M119 in October. If the origin trial succeeds, we are planning to send an intent so ship in M120, which gets cut at the end of October.

So, while we are happy to move in this direction, we'd like to time box this discussion and we would like to find some resolution on this before October.

Any chance we can get some early guidance from this group on whether this PR is an acceptable formulation (and, if not, a counter proposal?)?

We are planning to move from the API that we implemented towards what we described in the PR sometime in August/September, so it would be good to find some convergence before that.

[maceip]

My idea would be an API that makes it easy to set the "logged in" bit in various situations but make it impossible for a website to read its state directly. Instead, it can be used as a tool for 3Ps to privately alter the user experience on sites without learning about the user identity or logged-in state.

This strikes me as a potential case for (re)using private tokens (with private metadata bit) in reverse:

Log in event -> browser issues token with private metadata bit set to 1
sign out event -> browser issues token with private metadata set to 0

CWW

[samuelgoto]

Ok, just to report back from a series of meetings we had at TPAC here between @johnwilander @bvandersloot-mozilla and I, and close this issue, with a TL;DR:

• We managed to find a proposal that Firefox/Safari and Chrome liked (both short term and long term) and have collectively written it that down here.
• We are updating the FedCM spec to reference it here.

You can find the meeting notes of the Day 2 break out session here and the Day 3 FedID CG notes here where we met again to try to reconcile the last few open questions.

With that, I'm going to close this issue (with the answer in the positive: "Yes, FedCM should use the Login Status API.") and my PR.

@johnwilander @bvandersloot-mozilla feel free to let me know in case I got anything here wrong and re-open this issue.