-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should FedCM use the Login Status API? #53
Comments
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. |
I discussed this with colleagues and overall this seems like a reasonable way forward. cc @pascoej |
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? |
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. |
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 CWW |
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:
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. |
TL;DR; this is a proposal to use
navigator.recordLogin()
(rather thanIdentityProvider.recordLogin()
) to help raise the FedCM privacy propertiesFedCM 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 usingrecordLogin()
was a deliberate choice to get us closer to the Login Status API), and I think Mozilla is suggesting that we usenavigator.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 ofIdentityProvider.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:
The text was updated successfully, but these errors were encountered: