search

w3c-fedid / FedCM

A privacy preserving identity exchange Web API
https://w3c-fedid.github.io/FedCM/
Other
375 stars 72 forks source link

Support for SAML #479

Open spencer-strider opened 1 year ago

spencer-strider commented 1 year ago

Trying to confirm my understanding. FedCM does not currently support SAML correct?

achimschloss commented 1 year ago

Not a SAML expert, but as a more general remark FedCM does not support any protocol directly per se - implementing from the IDP perspective means in any case that you need to implement new APIs that replicate/replace certain parts of the standard protocol flows, as well as additional APIs to inform the browser (accounts endpoint, sign-in API etc.)

From an OpenID Connect perspective largely the parts that happen between the /auth endpoint call and redirect back to the RP (as well as the notion that unless the AuthZ extension is in place/used - also no standalone way as of now to interface with the user during authorisation).

The result of using FedCM will be an opaque token, which could be an ID Token, Access Token, Refresh Token (a combined representation) or anything you need to pass back to an RP to finish the process - i guess there are equivalents in SAML.

judielaine commented 1 year ago

I'm one of the co-chairs of the REFEDS Browser changes working group. In Higher ed there's a large deployed SAML infrastructure and we've been following the FedCM work closely. You can see notes of our observations at https://wiki.refeds.org/display/GROUPS/State+of+browser+privacy+evolution .

Currently there are elements for trust and assurance in SAML that are missing in FedCM. (We had documentation in February for this; i need to update it.) Since browser mitigations for navigational tracking currently do not impact SAML as long as none of the parties are on lists of known trackers used by Firefox and Safari, SAML continues to function per protocol.

The latest proposal from Chrome to mitigate navigational tracking is to monitor whether the user has any "real" interactions across the eTLD+1 site. If the user does not, and is bounced through some site (imagine a system that aggregates a number of RPs behind one RP that is federated to many IdPs), the cookies on that site would be removed after an hour. In the higher ed world there are impacts there that will require users to log in more frequently.

Were navigational tracking mitigations to be onerous enough that the SAML request on a redirect protocol was stripped and cross site posts became fraught, we have discussed (at an IIW side meeting in April this year) that FedCM could be used as a signal so the browsers would allow subsequent protocol exchanges. The IdP may provide a "universal account" and may return a universal opaque token, that would signal to the RP that trust was established and the SAML flow could begin. We have recognized that the many translation "hops" that can be cross-site would be very onorous and confusing for a user to establish consent. Conversations are continuing.