Eight years is a long time in any business, but that’s perhaps nowhere more true than the tech space. Indulge us for a moment, and let’s think back to 2010…

We saw Jesse Eisenberg forever linked with Mark Zuckerberg by The Social Network. Obamacare made its controversial debut. The cutting edge iPhone 4 also appeared in stores for the first time. 2010 also marked the birth of SCIM.

Kelly Grizzle of SailPoint joined us at our Austin API Summit in 2018 to tell us how SCIM went from a vague idea to something with three RFCs (use cases, schema, and API) that have been adopted thousands of times. But he also did a lot more than that.

In explaining the evolution of SCIM Grizzle provides a blueprint for any developer bringing an API to market in the open source/internet standard space, but his story (with the actionable tips, design lessons and unexpected applications we’ll take away from it) is one that anyone hoping to build a resilient and long lasting API can benefit from reading.

SCIM-ing The Surface

Let’s start with the basics. For those of you who don’t know, SCIM stands for System for Cross-Domain Identity Management but was originally known as Simple Cloud Identity Management.

It’s a REST API for identity management that was created with the following goal in mind: “Make it fast, cheap and easy to move users into, out of, and around the cloud.”

In 2010 OAuth was building a good market share and standardized authorization while SAML was creating standards for single sign on (SSO). “But there was a hole in this puzzle,” says Grizzle. “What about identity management?”

In the summer of 2010, at Cloud Identity Summit, a group of what Grizzle affectionately terms “identity management geeks” started kicking around the following problem: Because there were no standards for identity management, every product had its own unique identity management API, which made it hard for them all to communicate.

From Pet Project To API

Self proclaimed “identity nerd” Kelly Grizzle traces the journey of SCIM, from collab side project to well-adopted internet standard API.

On the issue of how to get started, Grizzle offers advice that’s along much the same lines as most pieces of Nike sportswear: just do it!

He explains how, in the case of SCIM, the main objective was to move fast and build momentum. More often than not that’s a smart move because gaps in the market, particularly when new and emerging technologies are involved, don’t stay gaps for long. Of course, more demanding projects require exploration of whether or not there’s a demand for the product.

SCIM 1.0 and 1.1 were developed under the Open Web Foundation, which offers (in Grizzle’s words) “a fast and loose way to share intellectual property.” It meant that people from different companies, areas of the world etc. were all able to come together and work communally with the legal side of things already taken care of.

Only later did the group move to Internet Engineering Task Force 9 (IETF) to make a more formal RFC. Obviously the “start casual, formalize later” approach won’t always be feasible for those working on behalf of organizations, but it’s worth bearing in mind for APIs that feel more like side projects than massive commercial undertakings.

Use Existing Best Practices

Grizzle says of SCIM that “we didn’t want to reinvent the wheel necessarily, we just wanted to…find the best practices and pull them all together.” In the API space, as is the case in most other areas of business, it’s wise to have your finger on the pulse of current best practices.

That doesn’t mean that you can’t deviate from best practices where you see fit, but you should at least know what they are. For Grizzle and SCIM that, in practice, meant surveying many existing identity management APIs:

• Used Portable Contacts as a basis for scheme
• Based querying and paging on OpenSearch
• Determine use cases by gathering from other APIs

In other words, once they knew there was a gap in the market for their product, they used data and methodologies that were already out there to build something that they knew (or perhaps hoped) could fill that gap.

Extensibility and Flexibility

Grizzle talks at length about the importance of flexibility when creating an API service: “If somebody sends you a response that looks a little bit off, try to just deal with it. Don’t just break immediately…Be a little bit more robust on what you allow within the front door.”

In the case of SCIM, this meant a core schema RFC that defines User and Group, as well as a language defining other schemas. This allows, for example, users to:

• Extend existing resource types (e.g. an Enterprise User)
• Add new resource types (e.g. IoT Device)

“If we didn’t have this,” Grizzle says, “people would take SCIM and throw it out the window immediately. If it’s not flexible enough, it’s not going to meet any use case.” He also quotes (Jon) Postel’s law for TCP implementation and reworks it for building a successful API: “Be conservative in what you do, be liberal in what you accept from others.”

It might sound obvious, but there’s no overstating how valuable flexibility and extensibility are to an API’s longevity. Many in the tech scene see APIs as being like Lego bricks, and trying to force a piece of K’Nex or a Super Blok into the mix can be seriously disheartening.

Expect Challenges and Surprises

Grizzle outlines a few of the challenges that the SCIM team faced when scaling and it’s worth mentioning them here because, although they might not be exactly what the average API developer will face when building a new product, there are certainly some parallels:

• The path to IETF is slow, but was worth the effort for SCIM because it increased exposure and allowed the team to get different perspectives on their work
• Were overly ambitious with their PATCH operation, designing it twice as a result, and Grizzle admits that there are things he wishes had been done differently
• Slow adoption – it takes time to hit critical mass, and you need evangelists or get early buy-in from key players to achieve exponential growth

Unfortunately, there are no easy solutions to most of the above issues. Grizzle jokes that “it’s good to have big friends out there”, but that doesn’t make it any easier to get companies like Salesforce or Google interested in what you’re working on unless you have an in with them.

Also, you should be prepared for people to make use of your product in ways very different to those you’re expecting. Grizzle mentions that SCIM was “built with cloud use cases in mind, but many of the first real-world implementations were at large enterprises behind firewalls.”

Final Thoughts

The story of SCIM differs from most of our case studies – which usually feature public-facing, partner or private/internal APIs – because it’s an internet standard API. The perspective may be a little different, but it’s interesting to note that all those processes have plenty in common.

While the challenges faced along the way won’t be exactly the same for all API developers, SCIM represents an impressive evolution from a side project dreamt up by a group of “identity management geeks” to a dominant force in the space used by Cisco, Salesforce, Google, and others.

Building an API, whether it’s a labor of love or part of a project at work (or both!), is always a daunting task. It’s refreshing to be reminded that a collaborative project dreamt up during downtime at a conference can end up becoming an open standard in its space.