[Openid-specs-fastfed] FastFed: Interop Profiles

[McAdams, Darin]

This is topic #4 in preparation for next week’s meeting. It describes why the FastFed specification defines interoperability profiles for SCIM, OIDC, and SAML.

Context:
-----------------------------
A personal anecdote:  When I first got involved in identity, I decided the right thing to do was read the SAML spec. I quickly realized the SAML spec was 7 different specifications comprising hundreds of pages. I read them all. Well, I admit to skimming a few. But, I tried. I came out more confused than ever and admitted to a teammate: "I'm struggling to understand this stuff."  They asked what I did, and when I said I'd read the whole spec, they laughed. That's when I realized that, for people who need to Get Stuff Done, a key to success was learning what to ignore. Only a small subset of the specification was relevant to the use case at hand: SSO into web apps.

Yet, even after filtering the noise, the specs left many things open to interpretation. Which signing protocol should I use? What schema? Do I have to host a metadata file? 

Many of us have experienced, or heard, the same frustrations. SaaS vendors tell us: "You identity people invented all these standards but haven't given us any guidance on how to assemble the pieces and do it right. Please, just tell us what to do." Without this guidance, the complexity and variability of the specifications is left open to interpretation, resulting in each application being a bespoke implementation.

FastFed is tackling this head-on. The user experience depends largely on consistency of implementation. The net result can be a win for everyone. By offering prescriptive instructions on how to implement SSO:
* Application owners receive the guidance they seek
* Identity providers avoid the integration overhead for hundreds of bespoke applications
* End-users get a simplified experience when configuring SSO

The goal of the interoperability profile is therefore to specify these rules. In essence, "Here's the stuff to pay attention to. Do it this way. Ignore the rest."
 
What's in the spec:
-----------------------------
The interoperability rules differ for SAML, OIDC, and SCIM.  Each is addressed in their respective profiles.

For SAML, the interop is defined in Section 5 of https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-SAML-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
It's 6-7 bullet points that basically say: "Implement everything in the SSO Profile that is REQUIRED. Host a metadata file. Use X509 signing."

For OIDC, the interop is defined in Section 5 of https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-OIDC-1.0-Draft-01.txt?at=master&fileviewer=file-view-default
It's 9 bullet points. More than SAML because of the extra moving parts around OIDC Discovery and Dynamic Registration.

For SCIM, the interop is defined in Section 4 of https://bitbucket.org/openid/fastfed/src/aa1cbce7c63e125b1304d327487d44aed12b7e02/text_spec/FastFedProfile-SCIM-1.0-Draft-01.txt?at=master&fileviewer=file-view-default

SCIM is a bit different than the rest. In the context of FastFed, it's used for synchronizing user data into a SaaS app. Engineers who are new to SCIM but have a background in storage or distributed systems often expect the specification to define a replication protocol, including anti-entropy mechanisms and concurrency handling. However, SCIM itself defines only CRUD APIs. It's an exercise for the implementor to combine those APIs into a robust synchronization system. 

Early adopters defined a process that worked for them and this effectively become a de facto standard.  For example, see the Okta guidance at https://developer.okta.com/standards/SCIM/ (Scroll down to "Required SCIM Server Capabilities"). The important callout is that providers don't need to fully implement the SCIM specification. It's a subset.

The FastFed interop profile attempts to standardize this subset. It defines the minimum required APIs and capabilities. In this first draft, the list is essentially cribbed from existing identity providers and codifies how things work today. Working group members with more experience in this domain may have better insights on best practices.  

Challenges:
-----------------------------
No prescriptive guidance works for every situation. The challenge is whether we can hit the 80/20 rule - a simple, prescriptive set of instructions that works for 80%+ of scenarios for SSO into web applications. (Personal comment:  I suspect that if we solve 80%, many of the remaining 20% will refactor to take advantage of FastFed and henceforth join the 80%+.)

The other challenge is evolving security. For the sake of argument, say "XX256" is the best recommended signing algorithm at a point in time. (That's not a real algorithm, just made up.) Naturally, we don't want to codify it as REQUIRED because security marches on. Five years from now, "XX256" is too weak and everyone needs to be on "ZZZ1024". So, we need to stay flexible. Yet, we also need to be proscriptive enough so that two providers who claim to be FastFed compatible can truly interop, and not hit a situation where one provider mandates "XX256" and the other mandates "ZZZ1024" and the administrator who simply wants stuff to work is expressing WTF.

I'm not comfortable with how the current version of the spec strikes that balance. In a couple places, it specifically mentions RS256 as a protocol that MUST be supported.

Discussion Topics:
-----------------------------
* Do the FastFed interoperability profiles define the right functionality to hit the 80/20 balance?  
* How to balance prescriptive instructions against the need to stay flexible for evolving security practices?