Recently the OpenID Foundation chartered a new Working Group (WG), the Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) WG.  Beyond Identity was one of the companies that proposed the WG, and continues to engage with the WG.  Below, we’ll dive deeper into Beyond Identity’s investment in standards development, and share our perspective on the value of the work happening in IPSIE WG.

Standards are Business Enablers

My colleague Sarah Cecchetti recently encouraged me to read the book, The Box, which covers the standardization of the humble shipping container.  (ISO 668, if you’re interested!) Standardization of shipping containers fundamentally changed the dynamics of shipping, manufacturing, and delivery of goods worldwide.

The primary technology change was creating a set of standards for container size, connectors, and maximum gross weights.  Containerization of shipped items instead of manual, one-by-one loading onto ships, trains, and trucks was a significant process change, reducing the amount of manual labor needed to move items from producers to consumers. 

In turn, these changes resulted in the development of dockside cranes, custom-designed container ship holds, and intermodal transport of containers, moving them from ship to truck to rail seamlessly while significantly reducing manual labor. Just In Time (JIT) manufacturing was unlocked by reliable supply chains with predictable shipping routes and timetables.  Intermodal transport enabled manufacturing facilities to be located inland, away from traditional shipping ports, where facility and labor costs are lower.  

Looking at this example it is easy to see that standards are business enablers. 

At Beyond Identity, we engage in standards development as corporate citizens to enable our business and our customers’ businesses, as well.  Over the next few months, I’ll write more blog posts about our standards engagement and the standards that support a secure by design product and integration patterns. Today, we’ll start with the latest standards working group that Beyond Identity is engaged in: IPSIE WG.

What is IPSIE?

Earlier this year, Aaron Parecki, Director of Identity Standards at Okta, reached out to request my support as a proposer of the IPSIE WG charter. IPSIE WG was formally chartered through the OIDF process in October 2024.  The WG began holding meetings the same month.  As with all OIDF working groups, IPSIE WG operates via a consensus model - all members of the IPSIE WG are equal contributors to the output of the group, enabling large and small organizations and individuals to contribute equally toward the WG’s goals.

Since chartering, I joined the WG as a co-chair to help guide the working group toward its goals alongside Aaron. Our goals are easily stated yet quite complex, “This working group will develop profiles of existing specifications with the primary goal of achieving independent implementations being interoperable, while also prioritizing secure defaults within the specifications.” 

What Problems Will IPSIE Solve? What are Profiles?

So what does this mean? Today, developers who need to implement common identity standards - OAuth 2.0, OpenID Connect, SCIM, SAML, etc. - are faced with a daunting task.  These standards are broad and deep, understanding them end-to-end is a bigger challenge than most developers want to tackle.  The standards are complex! They allow significant optionality during implementation. This leads to a myriad of implementation patterns and incompatible implementations by identity providers (IdPs) and SaaS applications (relying parties or RPs). Optionality of security features leads to implementations with varying risk profiles that may, or may not, be well understood by implementers.

Profiles are a mechanism to reduce the likelihood of incompatible and insecure implementations across one or more standards.  They deliver specific, narrowly focused implementation guidance by removing optional features in favor of concrete rules. Some examples of well known profiles include FAPI 2.0 for high security API protection, and the Shared Signals Framework profiles for the Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination (RISC). Profiles can be used to enforce secure by design implementations which address specific threats. Therefore, when implementers agree on a profile they can ensure that their systems are interoperable and meet the same security bar as others who’ve implemented the same profile.  

The envisioned IPSIE profiles will eliminate known insecure patterns, such as the OAuth 2.0 implicit flow, and require implementation of optional features that raise the security bar, such as PKCE and DPoP.  Additionally, we expect to deliver profiles that address increasing levels of implementation maturity and complexity, allowing implementers to choose the profile(s) which meet their needs. 

How Will IPSIE Impact Enterprises?

Enterprises, IdPs, and SaaS apps can expect more clarity regarding which protocols and options to choose for federated authentication, user and group provisioning, and signals about changes in the state of the user or their computing device(s).  Once IPSIE profiles are released, enterprises are expected to be able to choose the appropriate profile(s) required to meet their business objectives.  Enterprises procuring an IdP or a SaaS app can identify within their RFPs which IPSIE profiles are required by the solution to be a viable procurement option.

The working group’s early efforts toward defining levels has broken down the levels by function (e.g. authentication, provisioning) and maturity (e.g. level 1 provisioning may be just in time provisioning in response to a single sign on event, level 2 provisioning enables pre-provisioning of users and deprovisioning).  

Today, IPSIE WG has no published profiles or drafts, and there are no “IPSIE-compliant” services on the market.  Over time, through collaboration and consensus building, we’ll see draft profiles published through the OpenID Foundation.  The IPSIE WG expects to host future IPSIE interop (“interoperability”) events for IdPs and RPs to demonstrate their compliance with IPSIE profiles.  These early implementations will help the IPSIE WG identify and resolve any issues in the profiles before they are finalized. 

In the future, Beyond Identity expects that enterprises, SaaS apps, and IdPs will view IPSIE compliance as table stakes for enterprise identity services.  However, we’re not there yet - there’s a lot of work still to be done. As an early-stage standardization effort, now is the perfect time for individuals and organizations to get involved to shape the future of IPSIE.  Glancing through the IPSIE meeting minutes on the IPSIE wiki is a great way to see who is already engaged in this work. 

If you would like to get involved in IPSIE, please visit the IPSIE homepage and follow the instructions in the sidebar.  I hope to see you at a future meeting!