RE: [provision] A SIMPLEST profile for SPML2.

["Bohren, Jeffrey" <Jeff_Bohren@BMC.com>]

While I agree that having a standard schema to use with SPML 2.0 would
enhance interoperability, I fail to see how using SAML attributes would
be simpler that DSML attributes.

The way SAML and DSML define attributes are logically identical, with
the only difference that SAML adds the concept of an attribute
namespace. Note that this could just as easily be accomplished by using
a URI for the attribute name in a DSML attribute.

SAML does not define any of the other concepts needed for provisioning,
such as a provisioning schema mechanism (which you need to express your
standard schema), a way to indicate PSO Type, or a search mechanism.
Given that, I fail to see how you the profile you describe would be any
more "simplest" that the existing DSML Profile.

To me the "simplest" profile would be the Core capability, implemented
using the DSML profile, using a standard schema.

Of course this all supposes the existence of a standard schema, which
does not currently exist.  Without more progress on achieving a standard
schema, work on the "simplest" profile seems premature to me.

Jeff Bohren
BMC

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Saturday, July 23, 2005 5:16 PM
To: PSTC
Subject: [provision] A SIMPLEST profile for SPML2.

The idea for a third SPML profile came to me after I spoke with a 
colleague.  He asked how SPML was going, and I told him I felt that we 
had just specified something analogous to X.500 (that is, something 
complete and general but difficult to implement).  I told him I thought 
somebody would come along and pick a zippy subset of it , like LDAP, and

*that* subset would be what people actually ended up using.

That bothered me until I realized that we could define a *minimal 
profile* for SPML2.  It should be easier to implement (and easier to 
use) than either the XSD profile or the DSML profile.  It's similar to 
the DSML profile, except with SAML Assertion Attributes and a standard 
schema. 

The SAML Attribute syntax seems really simple and general.  I also 
expect that a lot of people will already be using it as they implement 
federation and SSO.

The standard schema promotes interoperability.  I'm betting that it's 
easier for both ends (requestor and provider) to map to a canonical form

than it is each end to operate with any other in its native
representation.

The standard schema also reduces the need to use capabilities. (The 
capability mechanism exists in part to compensate for lack of a standard

schema.  The Password Capability, for instance, allows a requestor to 
perform password-related operations without knowing the actual schema of

an object.  To be fair, the other purpose of the capability mechanism is

to make the set of operations extensible.  In this case, the set of 
*attributes* in the standard schema is extensible.)

In the first draft, the schema has Person, Account, Group and Role 
object classes.  (We'll probably want to add Organization and 
OrganizationalUnit.)  Each object class is modeled directory-style in 
terms of attributes.  Only the most essential attributes are required 
(e.g., name). You can also use any other attributes you like as long as 
they don't conflict with (and don't bypass) the standard attributes.  (I

suspect I'm stealing from the work we did a year ago toward a standard 
schema .)
 
Requestor and provider really need only the core (add, lookup, modify, 
and delete) operations.  You can do all the password-related and 
disable-related stuff through attributes.  (SPML2 requires listTargets, 
but the listTargetsResponse can be minimal.  Search is pretty 
desirable.  Nothing stops you from supporting other capabilities.)

Does anyone else think that a profile such as this is desirable?  I've 
started specifying the profile, but I don't want to go too far if no one

else thinks this could be valuable.

Gary

ps. I call it the "Standard Interoperable Multi-Purpose Lightweight 
Extensible Schema Template" profile (so I can have the acronym I want: 
SIMPLEST).  (My first thought was to call it the "Lightweight Identity 
Management Profile", but the acronym was unappealing.  :-)  
The only other good name I've come up with is "Known Interoperable 
Standard Schema".  (Some people may associate the acronym with "Keep It 
Simple, Stupid".  Let me know if you can think of better name for this 
profile.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php