Ian points out that the Liberty Provisioning Service specification does not use the Service Provisioning Markup Language (SPML). True, but Ian himself acknowledges that the type of provisioning being addressed here is different than traditional 'account provisioning', for which the SPML defined CRUD operations were designed.
As a user provisioning guy this model of provisioning looked a bit strange to me. Think telephone service provisioning, not enterprise user account provisioning.
Nevertheless, SPML is very much on Liberty's 'radar', but for a different set of provisioning use cases, ones more in line with Ian's traditional 'enterprise user account provisioning' (albeit with a federated twist). Using Ian's analogy, SPML is poised to move up in the office hierarchy, leaving the mop behind for the exciting world of mail-room cubbyhole creation.
Whether the Cardspace product team or OpenID community thinks about provisioning (and possible relevance of SPML) is a different matter. Is a priori or batch account provisioning even compatible with the hard-line definition of 'user-centric' identity that would have the user checking every packet as it flows by?
Tags:
2 comments:
Sweet! Mail-room here we come! Thanks Paul for the insight. Your last question was the one I didn't quite know how to ask. I have a feeling since federated provisioning doesn't get much air time and isn't widely deployed (if at all), the same will hold true for "traditional" provisioning in the CardSpace world.
There was definitely discussion about developing a SPML profile for account provisioning/restoration and de-provisioning/suspension within the Liberty Alliance.
I will let folks from the Liberty Alliance comment on the use cases defined and progress of this within the group.
-Raj
gavenraj@gmail.com
Post a Comment