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!!

[johnwilander]

Hi, and sorry for the delay!

@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).

This one is unclear to me. I'm the editor of Login Status API in PrivacyCG and I don't think Sam needs to join there for his work on FedCM. Likewise, I don't think I need to join the FedCM version of this as co-editor. Did Sam want me to?

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.

Do we have to rename it? It seems a bit weird to name an API high trust to imply that some other API is low trust. I think trust should be the default, no? I'm thinking of developers and making sure it's easy for them to get it right. They will not assume that the default is low trust unless they know about the sibling API named high trust. We should make sure developers' assumptions are typically right. So maybe the other API should be renamed?

[johannhof]

Hi, and sorry for the delay!

@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).

This one is unclear to me. I'm the editor of Login Status API in PrivacyCG and I don't think Sam needs to join there for his work on FedCM. Likewise, I don't think I need to join the FedCM version of this as co-editor. Did Sam want me to?

I think this is what we agreed on in the meeting but honestly I'm not sure why it would be needed either, so probably fine to skip? In any case it may be useful for you to give some feedback on the API to make sure we're not dramatically of-course from how you'd like the shape of the API to be, to help our long-term interop chances.

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.

Do we have to rename it? It seems a bit weird to name an API high trust to imply that some other API is low trust. I think trust should be the default, no? I'm thinking of developers and making sure it's easy for them to get it right. They will not assume that the default is low trust unless they know about the sibling API named high trust. We should make sure developers' assumptions are typically right. So maybe the other API should be renamed?

Well, I think sequencing it like this makes sense to me because we're working from simple untrusted login status (just call the API for minor benefits in privacy terms, like being able to use FedCM) towards complicated trusted login status (prove that a user signed in with you and get more significant functionality).

So, I think both semantically and with regards to implementation complexity for developers and user agents, it makes sense to consider high-trust an "upgrade" to opt into vs. the entry-level low-trust version.

[annevk]

I think the sequencing indeed makes sense, but you want to make it clear that the low trust API actually caries low trust, I think. Just like we identify unsafe APIs (and don't pretend we know what a safe API is).