TPAC - Future of Login Status

[johannhof]

At TPAC, we discussed the future of this repository as well as privacycg/is-logged-in and I believe we reached an agreement that I'd like to record here.

Discussion

• WebKit does not fully agree with the shape of the API as currently shipped in Chrome and was surprised this was shipped as-is. I don't think we discussed the full details of their concerns and will need to follow up on that (see next steps below).
• Chrome / @samuelgoto currently only intends to use this signal as a self-declared low-trust method of informing whether or not to show FedCM UI.
• @johnwilander wants to get a higher trust signal of actual user login state, with the intent to use this signal to inform potential relaxation in anti-tracking policies etc. (see privacycg/is-logged-in)
• We all agree it would be wasteful to have two separate APIs given the underlying semantics "is user logged in" are very similar. We still think last year's decision to unify the APIs with different "trust levels" was a good decision.
• Chrome / @johannhof does not oppose John's goals overall, but does not think that they're concrete enough to make a good WG work item. We'd like to understand what exactly is being proposed to have an opinion on it, i.e. how a trusted login status would be determined exactly, and which relaxations or other effects this signal would have.
• Everyone agreed that it seems non-harmful to have the underlying infrastructure for this kind of mechanism available through FedCM's login status anyway.

Next steps

• We will keep both repositories.
• This repo in FedID will be used for working on the API itself, with a focus on FedCM but making sure that it is forward-compatible with potential high-trust signal work.
• @johnwilander will join @samuelgoto as an editor and incorporate feedback from the WebKit team to ensure that we get to an interoperable state. TBC whether @bvandersloot-mozilla also wants to be an editor (it might not be necessary).
• The repository in privacycg/is-logged-in will be renamed (name to-be-bikeshed, maybe privacycg/high-trust-login-signals?) to clarify the current ambiguity.
• Through that repo, @johnwilander will continue to work on the high trust signal idea in PrivacyCG, specifically what interoperable mechanisms could use this signal today. @johannhof is happy to collaborate and brainstorm. A potential use could be for Bounce Tracking Mitigations (cc @wanderview).

Can I please get a confirmation from @johnwilander @samuelgoto and @bvandersloot-mozilla that this is a good way forward (or possible corrections)?

cc @hlflanagan

[bvandersloot-mozilla]

This seems like a reasonable way forward. I'd prefer not to be an editor :)

[samuelgoto]

LGTM

This matches my interpretation of what we discussed at TPAC. Thanks for writing it down!!