Re: [security-services] Official statement to W3C WG about impact on SAM

I'm sorry for being so late to this thread. I'm supportive of the SSTC weighing in on this issue with the W3C, but my sense is that it's really Chrome and Firefox (and Safari, but they are being typically "Apple coy" about participating in any of this at the moment) that need convincing, and a number of us have been regularly meeting with the former two parties, plus Microsoft, to good effect. We had a half-day side meeting at IIW two weeks ago, and got to a fairly decent place w/r/t unlocking browser functionality in support of enabling SAML/OIDC transactions to proceed if blessed by the user. We plan to get back together for another three hour focus session mid-summer, and reconvene at IIW in the fall. Hopefully somewhere along the way, the Chrome team and / or Firefox team will have time to ship a pre-release version of an updated navigator.credentials.get() (or similar) that will enable this functionality. Then we can play with it and see if it actually does what we need it to do, and how much of a UX hit it is.

I agree about a transition period being mandatory. This implies that there is a handshake to discover which mode is being used on a per user basis and that the Idp can simultaneously support connections of both types.

This doesn't mean all existing mechanisms (e.g. 3rd party cookies) have to work, but all user visible functionality has to still work.

Hal

On Thu, Mar 30, 2023 at 3:41âPM Cantor, Scott <cantor.2@osu.edu> wrote:

> My main goal is to understand the basic issues: What is the new architecture?

The long and short of it is that it's geared around the existing consumer model of very few IdPs (think Passport vs. Liberty, right?) so it doesn't scale in that sense, and it's very wallet-centric. It's quite like Infocard was IMHO, and is also designed much more akin to the SAML ECP model than the browser model, where the browser is in the middle of the exchange and each party is really just talking to that browser API and not each other.

> Can an IDP run in mixed mode with some
> users running SAML 2.0 and others running FedCM?

Yes, but that presumes the IdP is updated, it assumes RPs are updated, and it assume that the browser doesn't break the current model outright, which is what they are threatening to do. Since they won't actually confirm plans for what to break and when, that last one is impossible to answer, but *if* they started mucking with Redirect and POST data to address bounce tracking, it is a distinct possibility that current models break.

> Perhaps a useful step would be to create a list of principles which should be
> followed to phase in the new architecture.

"Promise to allow X number of years for transition" would be one of mine.

The meat of the higher ed proposal was basically to effect at least a short term model that wouldn't be as breaking a change while still allowing the fundamental goal of the user having to consent to the interaction.

It may be that that's a longer term solution or it could be the interim stage to allow X number of years to phase in FedCM as a replacement for existing protocols.

But when FedCM simply doesn't work because it's breaking things by design, and the response is "just tell us how to fix FedCM", it gets worrying.

-- Scott

security-services message