feedback on FedCM from BlinkOn

Hello all. 

I sent this email on the OIDC WG email list and was asked to re-send here. It was in the context of feedback from watching the FedCM presentation from BlinkOn (https://www.youtube.com/watch?v=9la0cBhVXac). The original email is below. 

Thanks.

------------------

I might be thick, but in my little world it feels like there's not a lot of appreciation for the potential damage that will be done by this. Here's my small world take.


First, my understanding is that there are lots of other clever ways to thumbprint browsers beyond cookies, so the premise that cookies are the main threat seems over simplified. Thus killing cookies in this way seems heavy handed given the collateral damage. If my understanding is correct, then the trackers will just work harder to use the other existing approaches. Perhaps I'm wrong and/or missing something? If so, I'd love the ELI5 [technical] explanation. This threatens the premise of this whole exercise.

Second, many of the examples used are of relationships between RPs and IdPs assumes social login that are third party situations (apps that signin w/ google, FB, apple, etc). There are so many more businesses out there that setup their own IdP that happens to be cross-site mechanically, but are in reality first-party in all other respects, and they have their own business rational for this. So it seems that the mindset of "oh everyone just uses one of the big social IdPs to login" is distorted from the reality of the relationships are between organizations and their users. Think of a hospital that has their own IdP to handle patients and the apps they need to login into to process their care. If this kind of thing is broken, then in your browser people won't be able to get login to get their chemo scheduling and follow up doctors visits (and I can tell you that apps in hospitals take years to get updated). Maybe you're aware of this already, but all the presentations I've ever seen don't seem to illustrate this level of understanding for non-social/non-enterprise login situations. I think the assumption there are only O(100) IdPs is very wrong/underestimated. Personally I have hundreds of customers/companies that run their own IdPs. I know the larger companies (Okta, Auth0, Gluu, ForgeRock, Ping, etc) have more customers than I do. That's at least many thousands of IdPs and the economic impact of this will be non-trivial.

Third, I think we've all learned over the years in the protocol space that having the browser involved as little as possible in communicating between the RP and IdP is a good thing. These proposals asking for the browser to take over all of this is... well... hard to grasp. It's a drastic shift from the momentum in the identity protocol space (e.g. PAR). The proposals I have seen in the video are trying to mediate protocol flows that are too simplistic (implicit flow w/ form posting id_tokens as the most common thing). Most scenarios I work thru don't pass id_tokens thru the browser, so these solutions seem presumptuous on protocol flows. Also, how do access tokens (for the underlying business APIs) fit into all of this, since that's the other half of what these protocols deliver to RPs?

Fourth, how do I get to write custom login UI during the login process? How does new user registration work in this world? What if I need to dynamically prompt for a MFA (or not) depending on the state of things? I might need to prompt the user for their email to federate to an additional external IdP (thus an additional hop) based on what the user inputs. I might need to accept custom parameters from the RP that affect the login workflow. I might need to introduce a 15-page workflow for a new EULA during login because of a change in the corporate policy. These things are very common and the exact reason companies setup their own IdP for their suite of apps and APIs. If the browser forces itself in the middle, that's a real deal breaker here, it seems. Why should the browser see user identifiers at all (and it doesn't quite help in the goal of reducing the the no-tracking goal)? So the assumption that solving login redirects w/ id_tokens and signout iframes as the main feature is wrong. I'm not sure this is the browser's job.

Finally, in my own personal browsing I use Firefox. I configure it to remove all cookies when I close the browser. I then explicitly configure the sites where I want cookies to be persistent. This seems like a nice way to achieve the purported goal without breaking the world. Why not make something like this the default? It's a hell of a lot simpler. I'd love to hear why this wouldn't work, and I was hoping back when we heard from the Firefox team that something like this wasn't a possible solution back when we had the 2-day W3C identity event. Again, assume I'm thick, so I'm sure I'm missing something here.


I'm sure as I actually spend more time getting into the technical details, I'll come across more issues/scenarios/questions. I'm happy to be wrong on all of my immediate reactions -- please share any links that corrects me on these concerns.

Thanks.

------------------


-Brock