OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RESTful SPML: Scope of use-cases to address?


Part of the appeal of SCIM is that it is RESTful.  Representing  
resources ("nouns) in a way that allows core operations to be  
accomplished using HTTP "verbs" (and allows other operations using  
special flavors of verbs such as POST) is an attractive design  
approach that works well with web technologies.  Another part of the  
appeal of SCIM is that it defines a "standard schema" with some  
facility for extensions.  However, at this time the SCIM draft  
describes mainly user-management use-cases, which is much smaller and  
simpler than the identity-management use-cases that drove the  
development of SPMLv2.

I know that a single provider can support both RESTful and SPML  
"bindings".  SPML as a protocol is verb-first, leaving open the  
"nouns": the schema of each target and the format of the payload.   
REST as an architectural principal is noun-first, leaving open exactly  
how to represent more advanced operations in terms of resources.   
These approaches are compatible, but I wonder how far we would want to  
go as a standard?

Just as a thought-experiment: Would we want to specify how to  
represent the entire scope of SPMLv2 (and to address all of its use- 
cases) RESTfully?  Everything that is in SPMLv2 is there for a reason-- 
usually having to do with the identity-management use-cases with which  
provisioning-systems deal.  Obviously, these identity-management use- 
cases are more complex than simple user-management, but addressing  
them in a general way requires more complexity.  How much complexity  
are we willing to tolerate in order to address richer use-cases?   
Nobody wants to be "Mr. No-Fun."

Let me ask this differently:  Which of the functions of SPMLv2 do we  
not need?  Or which are needed by everyone, and which are needed only  
by some?  We may be able to keep things really simple if we need few  
of these.  Otherwise, we must describe a general way to do all of  
them, even if most of the functions are optional. That's not a deal- 
killer; it just means that our standard may not look as attractively  
simple.

In SPMLv2, the core operations are those participants believed that  
most everyone would need.  Almost everything else that seemed very  
valuable but not always necessary became a standard capability, each  
of which is optional.  The Capability mechanism is extensible so that  
others can define and share capabilities not defined in the  
specification itself.  I'll list below some of the things we do in  
SPML so that people can say which would not be needed in a RESTful  
binding.  This isn't everything, of course, but it's enough to help me  
survey what a RESTful binding would need to be able to do.

1) ListTargets operation.  This is one of the core operations--the  
bootstrap operation--but you don't need it if you know ahead of time  
everything that a Provider exposes. It's valuable because it lets a  
requester discover the available targets (endpoints), and on each the  
classes of objects that are available to be managed.  For each class  
of object, it also lets you discover which operations are supported  
and which attributes are exposed.  If all you're dealing with is User,  
this might be overkill.  It makes a lot more sense if you're managing  
Users along with Accounts (and other types of objects) that may exist  
on any of several targets.  The ability to discover schema is  
particularly valuable with Accounts and other objects, where each type  
of target (e.g., application) may expose a different attributes with  
different semantics, and where the set of attributes may sometimes  
depend on the configuration and/or customization of the application(s)  
that the Target represents.

2) Async Capability.  SPMLv2 supports this optional mechanism because  
providers sometimes need to obtain approvals before they perform  
requested operations.  More generally, the mechanism supports any  
operation that the provider must perform asynchronously and does not  
wish to pretend is synchronous.  Within an IDM system, approvals can  
take an arbitrary length of time--hours or even days.  A big, long  
batch job might take so long to complete that the original session on  
the transport times out.  If you know it could take a long time, it's  
better to get back an ID that you can use to poll for status or  
results or to cancel that request.

3) Capability Data. This mechanism allows for add-on behavior (e.g.,  
where a set of operations requires/exposes additional data that is not  
normally part of the base object as it is persisted in the back-end  
application that the target represents.  These are particularly useful  
where a third-party component or service contributes additional state  
about each object.  Capability-specific data does not appear by  
default in a PSO, but SPMLv2 allows a requestor to specify whether the  
requestor wants it.

4) Batch Capability.  Allows one to "boxcar" individual requests.   
Similarly, provider "boxcars" results/errors.  Requester can specify  
whether to quit at first failure or keep chugging.  Requester can  
specify whether provider must process requests in order (or can  
process them in parallel).  This mechanism is widely useful in  
business scenarios, especially for synchronization purposes.

5) Bulk Capability.  Lets one do a "wild-card" modification or  
deletion; essentially the operation applies to the set of objects  
selected by a query. Highly efficient, obviously, where you need to do  
the same thing to a set of objects that can be selected.

6) Password Capability. Lets an administrator set a password, expire a  
password, and so forth.

7) Suspend Capability.  Lets an administrator enable/disable an object  
persistently (e.g., for vacation or sabbatical or termination).

8) Updates Capability. Lets you poll for changes.  Usually supported  
by time-stamps, change-log or change-queue.

9) Reference Capability.  Allows managements of relationships between  
objects, particularly where the relationship itself carries  
information.  Examples include a user's membership in an enterprise  
role, which could carry a start-date and an end-date for that  
assignment.  Another example is a user's relationships to one or more  
Organizations, e.g., reporting-relationship, dotted-line assignments,  
administrative responsibility for particular orgs.  (Weirder examles  
inlcude a user's permission or an account's permission to a particular  
object, which could specify particular actions that are permitted and  
various conditions under which each action is permitted.)

Please share your thoughts on which of these are still important.

Gary Cole


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]