Leverage users' prior relationships with their IdPs

[dhwalker]

Users will have a prior relationship with any IdPs they can successfully use for federated authentication. Extending the concept introduced in issue #51, how about providing a mechanism for registering an IdP as a trusted redirect target in the browser, with user consent, hopefully at the time the user registers with the IdP? This could eliminate the need to analyse the APIs used with those IdPs, even APIs that are yet to be invented.

[mitar]

This! I am glad somebody else raised this already.

After reading the spec, that was also my thought. A lot of complexity to allow some forms of authentication, highly tied to just authentication (no authorization) and OIDC, but leaving out a lot of flexibility and thus innovation current web platform allows. It also assumes IDP is evil (because it could be a tracking service) and prevents legitimate use cases where on the other hand it could be in fact serving as a protected of user's privacy (example of which I am working on at Charon).

In my view this could also just be solved with credentials.registerProvider which would provide some metadata about the provider, like link to privacy policy, terms of use, logo, name, etc., and ask the user if they want to provide this particular provider/origin/domain to allow 3rd party cookies exception. That would be all that is needed to help the browser with the classification problem.

And you could also have 3rd party allow lists and block lists (like ad blocking extensions do) to help the user decide which of those requests are legitimate if they are not familiar with them.

To me this is similar how websites ask for permissions to send notifications and for user's location. So why not just ask "I would like to be a IDP for you, do you allow? this would allow this site to track you". And if user is on the IDP they know and expect to be IDP, they can allow that. (Or company's policy can auto-allow/deny that for their internal IDP.)

Much easier to integrate for IDP. With similar outcome. Without having to determine a list of use cases to support or not.

[mitar]

And once registration is called, UA could even provide to the user three options a) always trust b) ask every time c) decline. And b) would then be that when a request against IDP's domain is made after some time of inactivity (or for current tab, or current browser session, etc.), UA asks again if such request can go with a cookie (of course we would not ask the user about cookies, but more like "provider IDP is attempting to authenticate you, do you allow that? (you have previously approved it)".

[samuelgoto]

Chrome looked into variations of this proposal in the past, but we quickly hit a wall with our privacy assessments: we need a user acknowledgement per RP/IdP pair, rather than */IdP, because we couldn't find any meaningful (e.g. considering comprehension, blindness and abuse) permission prompt that a user could acknowledge the */IdP permission.

One concrete immediate concern is that, if you make the permission */IdP, the IdP can track you across the * web. So, lets say you use once your favorite social login provider and accept a call to credentials.registerProvider(), we couldn't find a UX variation where the user would understand the consequences of allowing the social login provider (which are sometimes also big ad networks) to track you across the * web (in a way that doesn't put us back to where we started: third party cookies).

So far, this is believed to be a non-starter for Chrome.

@bvandersloot-mozilla does that match your intuition of where Firefox would arrive at too?

[mitar]

Thank you for your thoughtful reply. It is obvious that you spent a lot of time and thinking on this. Thank you for that!

I think even asking for RP/IdP pair would be fine. I mean, even current FedCM design prompts the user for RP/IdP pair, no? To authenticate. But then instead of doing the whole API thing, implementing account fetching, itd. Why not just prompt "IDP would like to sign-in you into RP" and if user says "yes", it redirects with full cookies to IDPs consent page (the first time) or allow iframe/silent requests in the future. I am a bit at loss at those additions to the API beyond just being a simple OIDC request gateway. In my view, FedCM could just be something like "I would want to start OIDC flow by going to X, please ask the user to approve and if they do, send cookies please". Browser prompts the user, if they approve, browser continues to the page. Heck, this could even be OIDC agnostic and be simply location.assignWithCookies(url) call which would prompt the user to approve 3rd party cookies (the first time) and the pair would be (caller origin, target origin) or some variation of it?

Also, there might be some opportunities to make it maybe be "top-level-domain/IdP" pair or something like that. So user might be able to say "approve RP/IdP but also approve any pair under the same domain" (with OIDC there might be multiple RPs/clients used by one app). Also useful in enterprise and other settings where there might be bunch of RPs/apps belonging to the same organization/community/tenant.

[dhwalker]

(Wow! Activity on a comment I made almost three years ago!)

I agree with Mitar about asking for RP/IdP pairs. In fact, given that users are each likely to be associated with an increasing number of IdPs over time, this would improve user experience by increasing the likelihood of suggesting the "right" IdP for the RP.

[cbiesinger]

@mitar isn't that proposed API essentially https://github.com/privacycg/requestStorageAccessFor ?

[dhwalker]

If I understand the proposed API correctly (which is not 100% likely), it seems that an IdP would have to be embedded in an RP's page (or maybe the other way around?) for this to work. Is that right? In the research/education federation space, there are hundreds of IdPs and more RPs. When users needs to authenticate, RPs invoke a discovery service to select an IdP that is acceptable to the RP and that the user says will provide identity information on the user's behalf.

For this to work, it seems to me that a more general process for registering the RP/IdP pairs would be needed.

[mitar]

@cbiesinger: Interesting. Thank you for pointing that out, but while I think it might work, to me it seems more complicated than necessary, or at least more complicated to get right. Especially with the fact of having to use iframes. My my main motivation is that I do not have much against having to do full page redirects from RP to IDP, but that I worry that browsers will start blocking cookies even in such case to prevent bounce tracking. So my question really is: how could I do a full page redirect and get the user to decide if they want to pass the cookies to target site. And browser could then remember (source, target) pair, which in context here would be RP/IDP pair, but the API could be in fact more general I think, without opening misuse (but it might be tricky to provide useful wording to the user what exactly they are approving, "do you want to send cookies when going from example.com to idp-example.com" seems very vague vs. "do you want to allow idp-example.com to sign-in you in into example.com").

After some more thought I think what would be needed is simply:

location.assign(url, {credentials: include})

So similar to how fetch has it. That would request from the browser that if url is of different origin than current origin is, to ask the user if you can send credentials to the target origin. So that would be then explicit opt-in to allow full page redirects to IDPs without being confused with bounce tracking redirect. So it would help the browser differentiate between bounce tracking and useful redirect.

Similarly, the server side could do the redirect by doing:

HTTP/1.1 303 See Other
Location: idp-example.com
Sec-Credentials: include

If whole FedCM was motivated by the classification problem between bounce tracking and legitimate redirects, I find the solution I proposed above simpler.