I had the honor of facilitating the Standards-Based Provisioning Special Interest Group at this year’s Catalyst conference. The participants believe that standards-based provisioning is at a crossroads and wish to publish the following statement. The statement is based upon our conversation; all of the participants have reviewed it.  I hope that the perspectives of these industry luminaries push the industry (and the especially the newly-reformed OASIS Provisioning Services Technical Committee) towards a viable provisioning standard.

——————————————————————————————————————-

Moving Forward on Standards-Based Provisioning

On Tuesday, July 27 a group met at the annual Burton Group North America Conference in San Diego to discuss the future of standardized provisioning and Service Provisioning Markup Language (SPML). The group readily achieved a consensus about two things: the need for standards-based provisioning and the qualities required for successful provisioning standard. The following people participated in the special interest group (SIG):

• Abdullah Haydar (Open Dealer Exchange)
• Andrew Ferguson (e2B2Bcom)
• Anil John (Johns Hopkins)
• Ash Motiwala (Identropy)
• Chuck Mortimore (salesforce.com)
• Jacob Farmer (Indiana University)
• Jonathan Sander (Quest)
• Mat Hamlin (SailPoint)
• Nick Nikols (Novell)
• Nishant Kaushik (Oracle)
• Steven Legg (e2B2Bcom)
• Tony Goulding (CA)

The participants have firsthand experience with the difficulties of proprietary provisioning from the perspective of both vendor and end-user organizations. The SIG meeting was particularly timely, as the Organization for the Advancement of Structured Information Standards (OASIS) is evaluating the need for an SPML v3 standard. Additionally, the SaaS market is at a critical juncture as vendors look for standards-based solutions to the provisioning problem.

SPML v2

The second iteration of the SPML standard was approved in the spring of 2006 and included additional capabilities and operational modes. In trying to address every possible use case, interoperable provisioning services leveraging the SPML v2 standard became impractical. Since the approval, few (if any) conformant implementations exist due to the complexity of the v2 standard. Additionally, vendor participation in the OASIS Provisioning Services Technical Committee (PSTC) has been nearly non-existent since v2 was approved.

Organizations wishing to use SPML must write provisioning services specifically for each vendor’s SPML implementation (if the vendor supports SPML at all). The difficulty in building a single, interoperable provisioning service has made the adoption of SPML by application developers a non-starter. Without adoption by enterprise and cloud application developers, SPML will not be adopted. In conclusion, the SPML v2 standard is broken.

Back to Basics

The next iteration of SPML should focus on solving “the connector problem” and provisioning use cases for cloud-based applications. That is, the next version of SPML should readily enable the development of simple, standards-conformant provisioning services for both enterprise and cloud applications.

The participants agree that a standards-based provisioning protocol is needed, and all concluded (except Chuck Mortimore) that it is best to evolve the SPML standard rather than introduce a new one (salesforce.com has not yet arrived at this conclusion). The next iteration of SPML needs to become simpler. It must support a simple use case for conformant, standards-based provisioning services. Additionally, the SPML standard is too imbalanced; it places too much burden on target applications. The participants assert that the next version of SPML must possess a “simple” profile for to be successful. The simple profile should include the following qualities:

• Provide basic create, read, update and delete (CRUD) operations.
• Focus on the default use case of a single provisioning service point (PSP) and provisioning service target (PST). This use case is the default one for application developers and end-user organizations.
• Eliminate transactional auditing requirements. In particular, the Updates capability places an impractical data retention and performance burden on the application.
• Support a simple search mechanism. The current search mechanism can create nearly infinite search parameters across all known user attributes, which places an undue burden on the application.
• Enforce conformance. Vendor’s products must undergo conformance testing prove interoperability. Conformance likely requires a reference implementation.
• Provide an optional, standard schema. An optional standard schema (like LDAP’s inetorgperson) provides a potential schema for immediate interoperability with other applications.

The Path Ahead

It is up to vendor and end-user organizations to move the SPML standard forward so that the industry can begin to build interoperable provisioning services. If you are interested in influencing the direction of standards-based provisioning and SPML, please consider participating in the OASIS PSTC.