FedCM lacks a OAuth/SAML Binding Profile

[samuelgoto]

By design, FedCM operates on a layer under userland identity protocols like OIDC/SAML. So, it is, by design, unopinionated about the security mechanisms IdPs and RPs use to make sure that everything is taken into account. For example, an IdP could (and, in fact, do) use JWTs to respond to RPs inside the token response, but the user agent doesn't inspect that to see if it conforms to OIDC (much like it is not the browser's responsibility to inspect the URL parameters in top level redirects, also used by OIDC/SAML).

Today, IdPs and RPs have both the OIDC and SAML specifications to look up to, and a series of choices (e.g. compliance tests, open source libraries and hosting services,) to assure them that their implementation is secure.

For example, if a naive IdP chooses to use FedCM, but forgets to use the audience field in the JWT, then it would put their RPs vulnerable to replay attacks. Because FedCM isn't a supported binding to OIDC and SAML (which is fair, since it is relatively new to those standards), they have to come up with their security choices by themselves (e.g. use audience or not), rather than reuse the years of security assessment made by OIDC and SAML.

Long term, my (personal) intuition (based on a series of discussion with the OpenID foundation and SAML members over the last few years) is that we should add FedCM as a supported binding to both OIDC and SAML, as an alternative to third party cookies and iframes. Doing so, would help IdPs and RPs be able to rest assured that their implementation conforms to a well studied set of security guidelines. In the long term, developers shouldn't have to know what FedCM is: they should rely on OIDC and SAML which, in turn, use FedCM as a binding (i.e. only OIDC/SAML's editors should have to know / care about what FedCM is). Some say that FedCM is sufficiently different from iframes/cookies that it makes the choices we took in OIDC/SAML outdated (e.g. redirect_uri is probably not necessary anymore and the security analysis probably needs to be reassessed), but I (personally) think it is easier to refresh those specs (and, importantly, retain the community around it) then to bootstrap a new one. What's right is largely to be seen.

In the short term, however, I'm not sure what options we have (maybe just form a set of community guidelines?), but we need to, as community, to come up with one. As more and more IdPs develop against FedCM (which we are starting to see as guidelines like this propagate), left unchecked and alone without guidelines, we are going to see the longer tail of IdPs struggle to make good security choices.

@timcappalli @hlflanagan any thoughts on how we could go about this?

[brdaugherty]

+1 on attempting to establish a minimum set of security requirements for FedCM.

Today, it feels as though there are differences in interactivity requirements, security, and privacy policies across browsers.
For example, Storage Access API variations.

For existing and new user-agents wishing to implement FedCM and for RPs and IDPs who provision web servers, applications, libraries, and enterprise policies a minimum set of security requirements and recommendations may help during provisioning and security risk assessments and audits.

For a FedCM deployment by an RP or an IDP a few examples of security related policies and settings which readily come to mind as potential Community requirements and recommendations:

• User gesture requirement to establish user presence and intent
• Cross-Origin-Opener-Policy
• Content Security Policy
• identity-credentials-get

OAuth, OIDC, SAML, would have their own, unique and additional requirements, but I wonder if a base set of user-agent, RP, and IDP requirements could be established and agreed upon as a starting point.

[samuelgoto]

There are at least two proposals that are currently being actively worked on:

• https://github.com/aaronpk/oauth-fedcm-profile and
• https://indieweb.org/FedCM_for_IndieAuth (in conjunction with Users can't use IdPs outside of the ones enumerated by RPs idp-registration#2)

There are a series of shortcomings that were identified as @aaronpk, @panva, @anderspitman, @sebadob and @obfuscoder, @michielbdejong gathered implementation experience designing these profiles and issues that we filed as a community as we went through this exercise (e.g. w3c-fedid/idp-registration#9 , #590, #587).

Many (most?) of these issues are absolutely constructive, well-defined, incremental and actionable on the design of FedCM, so we are planning to actively work on them so that the profiles don't need to bend backwards to make the protocols fit.

Still much to be done, but many thanks to the many involved for the amount of steps forward taken recently.