Re: feedback on FedCM from BlinkOn

And following up on my own email, to add a few more points:

> Yes, I have hundreds of customers that run their own OIDC/OAuth token server. These customers span industries (healthcare, financial, retail, biotech, government, etc)
> As for the users of these systems, they are usually customers of these companies

So the end users are often consumers. It could be a customer of an online retail shop, a citizen applying for a job with a government agency, a patient of a hospital logging in to get their lab results, etc. But it could also be the an employee of the online retailer, the government employee that's posting the jobs, or the doctor logging in to submit the prescription. 

Most of these users are not using some online identity from a SaaS or social provider, typically. And they are not always perma-logged into their accounts at the IdP. That's why FedCM's whole premise of assuming users are always logged in seems less common for the types of scenarios I'm dealing with. Perhaps these users (i.e. the consumers) only uses these systems once a month, but during their session they use 5 distinct apps that desire SSO across the user's time spent in them. And why are there 5 apps? That's just how the suite of apps that implement these business functions were designed -- perhaps one is in Java, one in .NET, one in PHP, etc. Mechanically from the protocol perspective they need to be different client apps, but using SSO and good CSS we're trying to hide that fact from the end user.

This is also why a consistent subject identifier for these users is very important across those 5 apps. These apps are implemented in such a way that they must act mechanically as distinct clients of the IdP, but from an end user's perspective they're all just part of the online retail shop, government jobs application, or online medical system for the hospital. I mention this because I noticed that pairwise subject ids was one goal of FedCM. That is a real deal breaker for these types of business architectures that need SSO. 

> Also, what about pure server-rendered apps? From what I could tell (and I might be missing something) FedCM does nothing to prove the user's identity to a backend. Perhaps those types of apps are not the target audience, given that it seems you're focusing on replacing the iframe techniques. So yea, maybe those are out of scope?

This point, now that I re-read it, is much more important when you start to block bounce tracking. There are many server-rendered apps that don't use JS in the browser, and rely upon session cookies to manage a user's session (thus my comments about no tokens in the browser). FedCM (or whatever spec/effort for the next phase dealing with bounce tracking) must absolutely support server side apps without JS. That's why the redirect workflows are so crucial to how things work today. The server-rendered app relies upon redirects and the session cookie at the IdP to achieve SSO. This is obvious to the protocol minded folks on this list, and perhaps to you as well, but I just wanted to re-iterate it to make it clear.

Thanks.

-Brock