IN PROGRESS
- There is no SAML back channel, and in some situations that's a security feature. (Therefore, any solutions to issues can't be deferred to the backchannel) Example: on site at national lab, i can access servers and i can access the internet, but the servers cannot access the internet.
- The "clientID" needs to support up to 2k in order to support the SAML request + sig; the "token" needs to support up to 100k (although perhaps that could be compressed before being sent...).
- SAML delivers assertions to a specific list of known endpoints (ACS); FedCM asks the IdP to trust the Origin
- SAML needs the IdP to be able to step up auth of users who may already have a session (and thus move users to a flow that may include redirects to MFA etc)
- [maybe] the FedCM spec seems to want the IdP to keep track of the RP clientIDs that an account is associated with. If the SAML request is shoved® into that value, it will always be unique. How much does that ruin the user experience.
This version of diagram as presented Mar 5, 2024 to Federated Identity CG.
