1
2
3
4
5
OASIS Service Provisioning Markup
Language (SPML) Roadmap
Committee Working Draft 0.1
14 May 2003
7
Document identifier: draft-pstcroadmap-01.doc
8
Location: http://www.oasis-open.org/committees/provision/docs/
9
Send comments to: pstc-comment@lists.oasis-open.org
6
10
11
12
13
Editor:
Rami Elron, BMC
Contributors:
14
15
16
17
Doron Cohen, BMC
Darran Rolls, Waveset Technologies
Abstract:
18
19
This document portrays concepts, objectives and major milestones of the SPML roadmap
plan.
20
21
Status:
22
23
This version of the specification is a working draft of the committee. As such, it is expected
to change prior to adoption as an OASIS standard.
24
25
26
27
If you are on the provision list for committee members, send comments there. If you are not
on that list, subscribe to the provision-comment@lists.oasis-open.org list and send
comments there. To subscribe, send an email message to provision-commentrequest@lists.oasis-open.org with the word "subscribe" as the body of the message.
draft-pstc-roadmap01.doc
1
28
29
Copyright (C) OASIS Open 2002. All Rights Reserved.
draft-pstc-roadmap01.doc
2
30
Table of contents
31
1.
Introduction
4
32
2.
Provisioning – so far
4
33
3.
A vision for provisioning
4
34
4.
More on SPML data and verb mapping
9
35
Appendix A. References
12
36
Appendix B. Acknowledgments
13
37
Appendix C. Revision history
14
38
Appendix D. Notices
15
39
draft-pstc-roadmap01.doc
3
40
41
1. Introduction
42
43
44
45
46
47
48
49
50
51
Over the last couple of years, we have witnessed a steady and significant increase in the
importance of provisioning. The term known by very few not too long ago is by now an important
piece in the enterprise IT jigsaw, and provisioning software proves to be an indispensable tool for
supporting and monitoring daily business operations in the burgeoning marketplace. Having said
that, the utilization of provisioning applications in organizations is merely a first step towards
realizing the enormous potential provisioning promises. Its importance is mostly evidenced in
managing internal company data, but we approach the point where provisioning services are
required on a much broader scale. The significance attributed to global digital identity, web services
and secured access to such services is a testament to this trend and an additional proof that the
key success factor for a provisioning vision lies in two things: standards and interoperability.
52
53
2. Provisioning – so far
54
55
56
57
58
59
60
61
62
63
64
Provisioning may be roughly described as the definition, management and automation of
processes, which govern the lifecycle of computer-stored identities. These identities consist
generally of users, but various implementations include resource identities as well. Implementation
of provisioning solutions varies from one company to another, but most share a common objective
– to address issues concerning administrative overhead and security risks inherent with
management of multiple account repositories. Hiring a new employee often necessitates the
creation of multiple user accounts in various applications and operating systems, according to the
relevant job description. During the course of employment, account properties need to be changed
occasionally to accommodate new job descriptions and new responsibilities. Upon job termination,
it is required to immediately revoke (and possibly remove totally) relevant user accounts to block
further access to restricted company data and resources.
65
66
67
68
69
70
These needs and more have spawned a long list of provisioning vendors and solutions. However,
lacking hitherto any standard definition and clear scope, provisioning has evolved to encompass
today many aspects of the ‘Identity Management’ space, including password management, access
management, and more. Add to that a proprietary service API for each vendor’s offering and it
comes to no surprise that even minimal interoperability between implementations is questionable at
best.
71
72
3. A vision for provisioning
73
74
75
76
77
Today provisioning is generally associated with ‘User provisioning’ or ‘Account Provisioning’. In the
future though, it is not inconceivable that provisioning will be used in the broader context of ‘Service
Provisioning’. One could likely envision an information world with service requestors, service
providers and service brokers (constituting a hierarchy of service) – all identifiable, and exploiting a
common, standard, effective, secure and scalable framework to exchange provisioning requests.
draft-pstc-roadmap01.doc
4
78
79
80
81
82
83
84
85
86
SPML stands for Service Provisioning Markup Language – a specification created by the OASIS
Provisioning Services Technical Committee (PSTC). The SPML initiative was born to answer an
urging business need – to offer a standard, expressive way to convey and exchange provisioning
data and operations between communicating parties. In light of the previous paragraphs though, it
is much more than a mere dialect. The specification is designed to play a vital part in stimulating
adoption of provisioning best practices. Thus, it comes to no surprise that SPML should be
regarded as nothing less than a standard framework to manage provisioning services in the future
marketplace. This becomes more apparent as one considers the impact provisioning has had on
businesses so far.
87
88
89
90
91
Current provisioning implementations often do not have much in common, even from the standpoint
of objectives. Whereas one company uses provisioning software to enable central management of
identity-based data, another might require such a solution for development purposes or even
auditing. Much of this stem of the fact that provisioning is neither a trivial term nor an easy concept
to grasp and it suffers from proliferation of ‘meanings’.
92
93
94
The current SPML specification is the first step in a path to establish a comprehensive provisioning
framework for global interoperable services. The SPML committee members made every effort to
ensure that even in its first version, the specification supports the following:
95
96

Ability to build effective solutions for client practical needs
97
98

Flexibility to incorporate changes necessary to accommodate changing market
requirements
99

Optimal utilization of existing and proven standards wherever possible
100
101

Freedom for service providers to offer extended functionality without breaching the
standard specification
102

Interoperability among service providers
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
Interoperability may mean different things to different people, but in the context of a provision-esque
language specification it probably translates best to letting requestors submit requests to a service
point with minimal (or no) concern with the particular provider’s service implementation. One
approach for a solution is to standardize on an appropriate set of verbs that mirror real world
provisioning requests. This approach has much appeal since it theoretically allows a requestor to
use a single format to request a given service from multiple service providers. A different approach
is to restrict provisioning verbs to a set of ‘core’ operations that act on a standard schema where
specific object classes and attributes mirror common provisioning scenario objects. So in essence
one approach favors the mirroring of provisioning ‘verbs’ whilst another favors mirroring of
provisioning objects. Alas, both ‘pure’ approaches do not lend themselves easily to accommodate
every imaginable provisioning scenario - at least not without necessitating some sort of extension
mechanism to be included in the model. Such an extension could allow any provider to still offer
requestors with access to non-standardized functionality. Of course – there is no interoperability in
this solution – bringing us back to square one. But there IS a solution. By combining the best of the
aforementioned approaches and introducing some necessary mapping functionality it is quite
possible to cover all the aspects needed to solve the interoperability challenge. These pieces
include (1) a data schema specifying PSTC-approved provisioning object classes and relevant
attributes; (2) a core set of generic operations (e.g. add, modify, delete), which can be used
independently, or sequenced to form complex workflows acting on the data schema objects; (3) an
ability to let providers extend both data schema and operation ‘verbs’ to offer clients with nonstandard proprietary provisioning services; (4) sequencing functionality to link several ‘core’
draft-pstc-roadmap01.doc
5
125
126
127
128
commands together to form complex commands, without resorting to proprietary, non-interoperable
verbs; (5) discovery mechanism to enable providers to expose the details of their service options so
requestors can learn about them and utilize them accordingly; (6) mapping specifications to link
proprietary verbs with standard verbs, proprietary objects/attributes to standard objects/attributes.
129
130
131
The PSTC decided to pursue the vision for interoperable provisioning in a phased approach,
starting with the implementation of a core operations model in which provisioning operations are
manifested by applying generic operations on a standard data schema.
132
133
The committee has devised a work plan focusing on the achievement of the following objectives:
134
135
136

Reach accepted definition of “provisioning”; preparation of a mission statement for
the provisioning service markup language (SPML)
137

Scope provisioning solution to be addressed by the specification
138

Define roadmap for achieving the goals set in the vision statement
139

Define deliverables of first phase major milestone – SPML version 1.0
140
o
Identify business scenarios where provisioning play a recognizable role
141
o
Identify roles and operations in provisioning scenarios
142
o
Typify provisioning scenarios
143
o
Identify services pertinent to provisioning scenarios
144
o
Define logic model for provisioning solution
145
o
Identify and review relevant existing standards
146
o
Define functions to support elementary provisioning services
147
148
o
Define protocol for submittal and reception of provisioning
requests/responses
149
o
Review protocol
150
o
Build prototype for feasibility/validity testing and demonstration
151
o
Submit version 1.0 for approval
152

Initiate work on roadmap phase 2
draft-pstc-roadmap01.doc
6
SPML
SPML
Named
Named Command
Command sets
sets
Provider
Provider
Named
Named Command
Command Sets
Sets
Client
Client
Virtual
Virtual Commands
Commands
SPML
SPML Mapping
Mapping Schema
Schema
SPML
SPML Standard
Standard Requests
Requests
SPML
SPML Extended
Extended Fields
Fields
Provider
Provider Extended
Extended Requests
Requests
SPML
SPML Standard
Standard Fields
Fields
Provider
Provider Extended
Extended Fields
Fields
SPML Version 1.0
SPML Version 1.1
SPML Version 2.0
153
154
Figure 1: SPML functional blocks
155
156
Inception
0
Phase 1:SPML v1.0
1
Interim Phase:SPML v1.1
1.1
1.1
Standard
Standard language
language for
for Add,
Add, Modify,
Modify, Search
Search and
and Delete
Delete
request
request types
types
XML
XML Schema
Schema protocol
protocol
Query
Query model
model for
for element
element discovery
discovery
Bindings
Bindings for
for SOAP/HTTP
SOAP/HTTP and
and file
file
Ordered
Ordered batches
batches of
of requests
requests
Synchronous
Synchronous and
and Asynchronous
Asynchronous execution
execution
Provider
Provider defines
defines Extended
Extended Requests
Requests
Core
Core data
data model
model (standard
(standard fields)
fields) –– v.1.1
v.1.1
Phase 2:SPML v2.0
2
Extended
Extended data
data model
model
Extended
Extended verbs
verbs
Integration
Integration with
with business
business process
process languages
languages
Named
Named Command
Command Sets
Sets
Mapping
Mapping Schema
Schema
Virtual
Virtual Routines
Routines
157
158
Figure 2: SPML roadmap
159
draft-pstc-roadmap01.doc
7
160
161
162
163
164
165
166
167
The functional specification of SPML v1.0 lays the foundation for realizing the provisioning vision by
defining a provisioning lingua franca. This offers clients and service providers with the means to
express provisioning directives and pertinent information in a standard fashion, using
straightforward verbs. While it borrows various aspects from proven standards, SPML is a genuine
protocol sporting features intentionally designed to support provisioning scenarios as befits a
provisioning-oriented standard. While planned to be addressed fully in the next version,
interoperability is maintained to an extent thanks to the core standard schema included in the SPML
specification.
168
169
The SPML version 1.0 specification features the following:
170
171
172

XML schema-based protocol for exchanging provisioning messages between a
client and a service provider.
173
174

Core provisioning operations for realization of elementary ‘micro-provisioning’ data
services – addition, modification, deletion and search
175
176
177

Query model providing a service-requestor (client) with an ability to discover details
about provisioning data and operations he is authorized to request with respect to a
given service provider
178
179
180

Ability for a service provider to define and implement Extended Requests –
specially constructed verbs for operations not covered by the SPML specification,
still conforming to standard rules.
181
182

Definition of batch requests – collection of operations requested to be handled as a
single entity of operation
183

Support for synchronous and asynchronous requests
184

File and SOAP/HTTP bindings
185

Core data model for maintaining an accepted level of interoperability
186
187
188
189
190
191
192
193
194
195
196
The SPML version 2.0 specification will improve on its predecessor in two main areas – the data
model and verb model. Focusing chiefly on interoperability, the version 2.0 specification will feature
a broader core data model for enabling a higher degree of interoperability than possible before. To
abet this, SPML 2.0 will specify two mapping protocols – one for data and one for verbs. The data
mapping protocol will enable service providers to support standard SPML field arguments while
implementing a different proprietary data model. The verb mapping protocol shall enable a
proprietary request verb to be used in lieu of a corresponding standard request. Coupled with a new
functionality to support naming of command sets, it will be possible to create complex ‘macro-like’
commands consisting of (ergo – mapped to) ordinary ‘core’ commands. The core set of commands
defined in v1.0 will be enhanced as well.
197
198
In addition, SPML v2.0 will be revised to accommodate new emerging standards available by then
(e.g. BPEL).
199
200
draft-pstc-roadmap01.doc
8
201
The functional specification of SPML version 2.0 will address the following:
202
203
204
205
206
207
208
209
210
211

Extended and expanded data model scheme – new and revised fields
SPML 2.0 will build on the framework presented in SPML 1.0 and 1.1 while adding
new functionality to support creation, management, discovery and mapping of “field
namespaces” – named definition sets of fields relating to a particular market
segment. Such functionality could allow separate parties to agree on a standard
‘field set’ and refer to it in a standard manner, without necessitating the
involvement of a standards body to incorporate the specific data into a common
schema. The role of SPML is to specify a standard for the creation, format,
publication, discovery and usage of such data.
212
213
214
215
216
217
218
219
220
221
222
223
224
225

Extended scheme for standard verbs
SPML 1.0 provides a powerful way to express provisioning requests. However, its
interoperability chiefly depends on the adoption of a standard schema specifying
common and accepted objectclasses. It is reasonable to assume that in order to
facilitate scalability and still ensure interoperability, some sort of federation or
distributed scheme should be used. SPML will address these cardinal issues in two
aspects. From the data perspective, SPML 2.0 will specify a standard model for
schema hierarchies and relations. From the operation side, SPML 2.0 will specify
an extended set of standard verbs (in addition to the existing ‘core’ add, modify,
search, delete), which will be in fact mapped sequences (see named command
sets) of core verbs with ‘pre-configured’ attributes, albeit with options to let an
implementer add (but not remove!) additional commands to the sequence. This
way, there will be a common understanding of what basically constitutes a
command, while still enabling extensions by service providers.
226

Support for field and verb mapping
227
228
229
230
231

Support for named command sets
SPML 2.0 will support the creation of core verb sequencing – i.e. the chaining of
add, modify, delete, search verbs acting on specified objectclasses, and using
specified attributes – under a given name. This named request will be referenced in
the schema and could be referred similarly to ordinary core verbs.
232
233
234
235

Expanded discovery mechanism for provider capabilities
SPML 2.0 will expand on the discovery specification of version 1.0 to enable
requesting authorities to discover functional enhancements introduced in any new
version of SPML in addition to the capabilities already supported before.
236

Accommodation of new relevant standards
237
238
4. More on SPML data and verb mapping
239
240
241
What is SPML data and verb mapping? Simply put, it is a means for enabling translation between
any two SPML-supporting providers’ proprietary (i.e. extended) provisioning dialects (PD) - using
the standard SPML schema as a common denominator ‘bridge’.
242
243
As the SPML schema is still in its infancy and evolving, it obviously does not address yet every
possible provisioning scenario, and it is arguable whether ANY schema could ultimately provide
draft-pstc-roadmap01.doc
9
244
245
246
247
such capability along with unanimous concurrence of all provisioning services to adopt it AS IS. In
reality, service providers and vendors alike will each continue to strive to offer a smorgasbord of
new features along with enhanced functionality that requires the addition of new, non-standard
objectclasses or the use of extended requests, thus impeding the vision of interoperability.
248
249
250
There are compelling reasons to implement mapping. First and foremost is interoperability. Within
the SPML provisioning vision, interoperability ultimately translates to two things:
251
252
253
1. Letting any SPML-compliant requestor (SR) use a single un-modified PD to request
provisioning services from any SPML-compliant provider (SP) (e.g. submitting a single
format revoke request for an account.).
254
255
2. Letting any given SP construct a single un-modified PD to communicate with any SR (e.g.
responding uniformly to a revoke request submitted by non-uniform PDs).
256
257
Why is all this needed? Here are just a few examples:
258
259
260
1. An SR needs to access multiple SPs for a similar service, however each of the SPs has a
different implementation of objectclasses and verbs. The SR does not want to implement
multiple request dialects.
261
2. An SR wishes to replace the SP, sans modifying PD code.
262
263
264
3. An SR employs a complex request model and favors submittal of high-level requests that
mirror this model over submittal of simpler ‘atomic’ requests. Moreover, the SR wants to
receive responses correlating to such requests.
265
266
4. An SR wishes to use the services of a specific SP, but not at the expense of using
proprietary requests and losing interoperability.
267
268
5. An SP wishes to implement extended functionality that is not covered in the SPML standard
spec – but without resorting to non-interoperable Extended Requests.
269
270
6. An SP wishes to use a different term for specific objectclasses and verbs without breaching
compliance to SPML standards.
271
272
273
To facilitate such capabilities, translation services are required, providing some sort of mapping
between specific PD elements and SPML standard schema elements.
274
275
The following is a non-exhaustive list of questions that arise with respect to dialects:
276
277
278
1. Who is entitled to define a PD? Is every SR entitled to do so or is the ‘creation’ of a PD a
prerogative given to specific parties? If yes – who is involved here? Who authorizes the
PD? Who maintains the PD?
279
280
2. What kinds of verbs and data are allowed to be mapped? Are there exceptions, or is
everything map-able?
281
3. How (if at all) is dialect mapping related to the SPML support for internationality?
draft-pstc-roadmap01.doc
10
282
4. Who provides the dictionary for a PD?
283
284
5. How is the dictionary constructed? What does it include? Who is responsible for the
dictionary spec?
285
286
6. Who is responsible for performing the mapping (the Mapper) – is it the SR, the SP or a 3rd
party specialized service?
287
7. How is the Mapper referenced in a provisioning message?
288
8. How does one discover Mapper services?
289
9. How are Mapper services described and accessed?
290
10. What is required from SPs to support PDs? What is required from SRs?
291
292
293
294
295
296
Obviously, finding an optimal solution to all those questions is not trivial, yet not necessarily a
staggering undertaking either. Given the aforementioned issues, it is reasonable to regard the
SPML schema not as THE provisioning sole dialect but as a core foundation for constructing
provisioning dialects, furnishing service providers with the proper building blocks to express any
complex sequence of requests and responses deemed necessary.
297
298
299
Such a mechanism would allow providers to construct their own custom dialect based on the SPML
core building blocks. By having providers support a common standard mapping scheme, it is
possible for customers to converse with any SPML-compliant provider.
300
301
draft-pstc-roadmap01.doc
11
302
Appendix A. References
303
304
305
306
draft-pstc-roadmap01.doc
12
307
Appendix B. Acknowledgments
308
309
The following individuals were voting members of the Provisioning Services committee at the time
that this version of the specification was issued:
310
List Members Here:
draft-pstc-roadmap01.doc
13
311
Appendix C. Revision history
Rev
Date
By whom
What
D-01
14 May 2003
Editor
1.0 SPML Roadmap
312
draft-pstc-roadmap01.doc
14
313
Appendix D. Notices
314
315
316
317
318
319
320
321
322
OASIS takes no position regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such rights. Information on
OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS
website. Copies of claims of rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of this specification, can be obtained
from the OASIS Executive Director.
323
324
OASIS has been notified of intellectual property rights claimed in regard to some or all of the
contents of this specification. For more information consult the online list of claimed rights.
325
326
327
OASIS invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology that may be required to
implement this specification. Please address the information to the OASIS Executive Director.
328
Copyright (C) OASIS Open 2002. All Rights Reserved.
329
330
331
332
333
334
335
336
This document and translations of it may be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by removing the copyright notice or
references to OASIS, except as needed for the purpose of developing OASIS specifications, in
which case the procedures for copyrights defined in the OASIS Intellectual Property Rights
document must be followed, or as required to translate it into languages other than English.
337
338
The limited permissions granted above are perpetual and will not be revoked by OASIS or its
successors or assigns.
339
340
341
342
343
This document and the information contained herein is provided on an “AS IS” basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
draft-pstc-roadmap01.doc
15