A SIMPLEST profile for SPML2.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

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.