Integration with FedCM (formerly WebID)

[johnwilander]

Federated logins, i.e. login on a relying website from OrganizationA through an Identity Provider (IDP) from OrganizationB, have been discussed for IsLoggedIn all along. See for instance issue 35 and issue 30.

WebID could potentially be integrated with IsLoggedIn by becoming a standardized "mediated login" which makes it easy for the browser to reason about the user's login state and provide a nice path for both the identity provider and the relying website to set IsLoggedIn.

We should work with the WebID team to see if such an integration makes sense.

[TheMaskMaker]

First I'd like to flag there are other solutions to cross login than webID being discussed at present. We should discuss the larger problem at the F2F of how this works in various proposals, as browser-controlled login is not necessary in some of the current privacy proposals.

For those proposals that do require it, I'd like to flag some publisher level worries here around any browser-controlled login. Currently login is a publisher-controlled technology. There are some concerns with various browser mediated solutions causing the following threat models, some privacy threats:

• browser corporation monopolization of login technologies which currently lie under publisher control. This threat could give a browser the ability to shutdown login practices arbitrarily without community or standards approval in the future.
• browser corporation snooping of publisher level login or user tracking that could steal or leak valuable data from publishers to browser-aligned advertising, big data, or other affiliated, or even to competitors or the general internet through open technology. (This threat model has already been identified in various floc issues for example: https://github.com/WICG/floc/issues/45 https://github.com/WICG/floc/issues/41 )
• exposing user data to a company (browser, other as above) that did not necessarily seek legal opt-in via gdpr/ccpa or other privacy laws via the current publisher-controlled cmp standard.

While this technology could solve some of the cross domain issues created by some of the new privacy proposals, steps would have to be taken to prevent the browser from having any undue influence or insight into the login process itself.

I think there is a great deal to discuss here. A solution in which the browser is oblivious to the state of the user or type of login could potentially have some value.

[samuelgoto]

We should work with the WebID team to see if such an integration makes sense.

I need to take a closer look at the specific semantics and consequences of isLoggedIn, but on a shallow inspection, they sound like a reasonable implication of the WebID mediated flows.

That is, yes, we would love to work and understand what's the implication (either way) between isLoggedIn and WebID.

[samuelgoto]

Having skimmed through isLoggedIn recently, I wrote down some thoughts on my mental model of the relationship between these two APIs here.

[melanierichards]

Added some comments to https://github.com/WICG/WebID/issues/71

[samuelgoto]

Just to report back on this thread here, we recently polished our explainer with a better section for "related work" and "alternatives considered" and we tried to capture our best interpretation of the Login Status API and how it relates to FedCM here:

https://github.com/fedidcg/FedCM/blob/main/explainer.md#the--login-status-api

Let me know if I got any of this incorrectly, and I'd be happy to course correct.

[bvandersloot-mozilla]

So the JS API in-browser for FedCM is built on the Credential Manager API. Specifically a new Credential type, the IdentityCredential.

This seems like a natural place to start from. But I think there is a tension here between the way the Credential Manager API assumes things work and what Login Status wants to achieve. The Credential Manager doesn't have any concept of partial observability: you either get a Credential or you never know of its existence.

I think to these to work together you need to change the Credential interface itself to allow a Credential to allow its presence to be observed without sharing any tokens/passwords/etc.

Unfortunately this gets confusing because other Credentials don't have a conception of a session, but I suppose they can just mark themselves as not visible.

Another part of a way forward on this to add a [[Create]] internal method to the IdentityCredential from FedCM that would be called on login to the IDP. This could also be a part of some other discussions on FedCM we are having around user flows. This does still leave the trustworthiness of a login status bit's continued presence in the air, which leaves a Defending Against Abuse approach necessary.

[samuelgoto]

Ok, just to report back on this thread here, @bvandersloot-mozilla and @cbiesinger are starting to find some convergence on how to handle the timing attack problem through an API that allows Identity Providers to record their user's sign-in status: an IdP Sign-in Status API.

I think this is likely a strict subset of what was originally proposed by @johnwilander on the Login Status API in a few ways:

1. it is (by design) intended to be used only by Identity Providers, rather than any arbitrary website
2. it only records the user's sign-in status (a bit) rather than the user's metadata (e.g. name, email, id, photo)
3. it has very specific semantics and consequences narrowly applied to FedCM's account fetching model

Because of the narrow semantics and consequences, we can be more confident about abuse and where to insert UX controls to prevent it.

This an early idea, but one that we are starting to become increasingly excited about, so I wanted to report back to this thread here in case there is interest in coordinating between the Login Status API and FedCM's various needs to know when the user is logged in to the IdP.

[johnwilander]

There is absolutely interest in coordination. I will be at TPAC 2022 in person Mon-Wed. Will you, Sam? If so, we could talk about this.

[samuelgoto]

There is absolutely interest in coordination. I will be at TPAC 2022 in person Mon-Wed. Will you, Sam? If so, we could talk about this.

Yes, we will be there the whole week.

We are starting to prepare for TPAC and we have a series of meetings that we are planning to attend in person:

• FedID CG Monday/Tuesday 10h30am-12pm
• Privacy CG Monday 1h30pm-3pm
• Related breakout sessions (FedCM and Same Party Federation)

We also have some space that we are going to use for smaller group meetings if you are interested.