Nothing Good Stands Still

Throughout my career in identity I have found that understanding the standards behind the technologies I’ve used has been critical to successful projects. My standards knowledge has helped backstop missing or inadequate product documentation and troubleshooting issues between COTS products and custom-developed apps. I have had conversations with peers whether such a detailed understanding should be necessary for an enterprise engineer, with the consensus being that it shouldn’t be. Unfortunately, my experience has shown at least a working understanding of the standards is incredibly helpful. This understanding has driven my career toward efforts to make standards more approachable and less opaque.

I’ve previously presented at Identiverse on troubleshooting federation connections and examining potentially challenging capabilities in federation protocols. A common thread in these previous presentations, and those by others, is that protocols or protocol families evolves over time. My presentation this year was directly about protocol change and how to stay informed about those changes.

One of the challenges with standards of any kind is there are so many to choose from. Cue xkcd…

Not only are there are an incredible number of standards, there are multiple standards bodies. OAuth is a product of the IETF, OpenID Connect is out of the OpenID Foundation, SAML is from OASIS Open, and WebAuthn and FedCM are developed in the W3C. Each of these organizations have different names for their in-process and final specifications, making the landscape somewhat more difficult to understand for those that are not invested in the standards community. Even in this diverse landscape there are common properties of specifications from these bodies.

First, these specifications are intended to be complete. This means that the specification fulfills its stated goals. Second, the specifications are designed to be clear, meaning that requirements are well understood. Additionally, there is no ambiguity that a feature is mandatory or optional. Lastly, a specification needs to be stable, once a specification is finalized there are no normative changes that could alter the meaning of the specification.

While individual specifications are not intended to change, that does not mean that the protocol that it defines cannot. The way a protocol changes is through the development and promulgation of new specifications. The reasons for evolving a protocol or standards family are varied, but include:

• Ongoing security analysis
• Development of related technologies
• Evolution of best practices
• Updates to upstream references
• Changes to technical dependencies

These evolutions are evident in recent standards development such as the publication of RFC 9700, the current best practices document for OAuth 2.0 security.

The evolution of specs poses a challenge for both implementers of protocols in products and those that integrate between identity providers and applications. While it shouldn’t be surprising that implementers must plan for ongoing security updates, ongoing evolution of specifications invariably means that products that implement these protocols must have continued feature development and security analysis beyond what was originally planned. Further, for integrators, a challenge arises where products and specific implementations do not implement the same subsets of these protocols. This is a driving reason for the development of IPSIE to assist with ensuring interoperability.

OAuth 2.0 originated in a draft about fifteen years ago and was finalized in RFC 6749 in October 2012. There are now more than 30 specs that define aspects of the protocol and more than 100 specs that are related and intertwined with OAuth. The core set of specifications represents innovations like PKCE, additional client authentication methods, and server issuer identification. Additionally, features have been deprecated including the implicit and resource owner password credentials grants.

OpenID Connect is included in the larger set of specifications, as OpenID Connect is built atop of OAuth 2.0. As previously mentioned, OpenID Connect is a product of the OpenID Foundation while OAuth is developed in the IETF. Each of these organizations have their own processes for developing and adopting specifications, but generally have similar priorities around transparency and consensus. Many participants engage in both working groups, but they are certainly independent and distinct.

Given all this, how can those with a stake in identity standards handle this kind of evolution?

First, stakeholders need to understand some fundamentals about how standards work. While individual specifications are stable and not changing, the larger ecosystem of specs is interrelated and highly dynamic. Additionally, evolution in families of specifications needs to be expected — if there isn’t ongoing development in a set of standards, the likelihood that products based on those standards become “legacy investments” goes up dramatically.

It is also necessary for stakeholders to get involved in the standards community, even if only in a minimal way. At the most basic level, keeping up with the publication of standards is necessary. For the IETF, the RFC Editor provides an RSS feed of recent publications. Most standards organizations maintain public mail archives for their working groups as well as news pages that can be reviewed. Beyond that, please consider actively participating in relevant working groups and professional organizations. Share your use cases, experiences, and challenges.

Dipping a toe in the world of specifications can be a daunting experience for someone who may not have the background knowledge or experience. Thankfully, the identity standards community is largely a welcoming place and willing to help those new to the space. I am personally working on a project to help better understand the complexity of interrelated standards and specifications. I hope to have more to say on this soon. In the interim, if there are any questions or suggestions please reach out and I’m happy to help.

If you are interested in starting to engage the standards community, some recommendations to get started include:

• IDPro. The membership of IDPro includes many participants in the identity standards community. The IDPro Slack is active and a great starting point to meeting others that share your interests. The Body of Knowledge is a fantastic resource to expand your understanding across many areas of identity.

• IETF. The IETF is home to multiple working groups for identity related topics. The IETF provides a guide to getting started with participation in the org. In my experience, participating in an IETF Meeting remotely is completely viable and surprisingly enjoyable.

  • Web Authorization Protocol (OAuth) WG. The OAuth working group is home to the core RFCs for OAuth. There are multiple in-process Internet Drafts as well as independent drafts that may be adopted by the working group.

  • System for Cross-Domain Identity Management (SCIM) WG. SCIM provides a protocol for coordinating identities across multiple domains, which includes syncing identities to SaaS platforms. The current goal of the working group is to revise the existing RFCs incorporating experience and feedback.

  • Workload Identity in Multi System Environments (WIMSE) WG. Workload identities are a historically challenging concept in the identity world. They are significantly differentiated from personal identities and have unique requirements and challenges. The WIMSE WG is working to assess this space and develop solutions to address those challenges.

• OpenID Foundation. The OpenID Foundation is home to many standards including OpenID Connect, FAPI, Shared Signals, and others. The Foundation’s standards work is done, much like with the IETF, in a variety of working and community groups.

  • AB/Connect WG. This is the home of OpenID Connect and its related specifications. Current work in the working group includes native SSO in mobile apps, OpenID provider commands, and OpenID federation.

  • Shared Signals WG. The Shared Signals working group is home to CAEP and RISC. These technologies are key elements in the development of the concept of “Continuous Identity”. This is a seismic shift in managing session state in a world of dynamic state changes in user accounts, client status, and risk evaluation.

  • Digital Credentials Protocols (DCP) WG. The ecosystem of DCP is the basis for presentation-based identity verification, such as mobile drivers licenses and other similar credentials. At Identiverse, verifiable digital credentials were a huge topic and this working group is one of the key spaces where this work is being done.

  • Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) WG. As discussed, optionality in specifications can lead to difficulty in interoperability. The IPSIE WG is working toward developing a profile for protocols to improve interoperability in the enterprise space for at least session management, including sign-on and sign-out, and user lifecycle management.