[provision] SPML - extending SAML and DSML

[Darran Rolls <Darran.Rolls@waveset.com>]

Folks

Acting as a committee member (not as chair) I have pulled together the
following outline proposal for basing SPML on the SAML assertion
framework. I certainly would not consider myself to be a xsd wizard so
try and focus on the intent rather than the syntax ;)

There are two attachments.  The first is some rough sample code, the
second is a simple ppt picture that summarizes this proposal.

Outline
=======
This proposal calls for SPML to consider the SAML assertion framework as
core foundation technology.  SAML has been developed to provide an
extensible framework upon which assertion based applications (and
specifications) can build solutions.  Is SPML and assertion based
specification?  This is valid question, asked here and left open for
debate.

As far as extending SAML, the 1.0 specification defines no "final" xsd,
so in theory anything goes.  However, as a start point, this proposal
suggests leveraging the established extension points of
<StatementAbstractType> and <SubjectStatementAbstractType> to provide a
range of new <SPMLStatement> and <SPMLSubject> elements.

Along with basing SPML's core schema on SAML, this proposal suggests
extending the SAML <Request> & <Response> elements to include batch
handling much like the DSML v2 xsd.  Although this could be called out
to SPML v2, I'd like to include it in V1 as the bulk of the hard work is
done, ready to lift straight into SPML.

Why base SPML on the SAML assertion framework?
==============================================
1 - Re-use.  SAML has defined a lot of the material work of defining a
security and binding model that we can simply make direct use of.  As
SAML hits issues and works around them, SPML directly benefits.  

2 - Credibility.  IMO, SPML is a critical part of what you need for web
services security.  If we base SPML on an established and accepted
standard, the likelihood of SPML being more widely adopted increases.

3 - Ease of use.  There is a growing body of understanding around SAML.
If out model has a similar "feel" we could reasonably expect an easier
learning curve and very possibly increased support in development tools
etc.

<Statements>
===========
At a very fist pass, it looks like this approach could collapse out
protocol use cases down into the following new extended SAML statements:

PSU-Statement - around which all PSU CRUD is specified
PST-Statement - around which all PST CRUD is specified

With cleverly defined xsd for these two primary statements we *should*
be able to detail all of the use case operations. 

<Subjects>
==========
We would most probably have to extend the SAML subject statements as
well to allow for identification of the PSU.

Sample code
===========
I didn't want to spend too much time defining sample xml if this idea is
not going to fly.  The attached sample.xml should be enough to open a
discussion to quickly asses is this is worth applying more bandwidth to.

--------------------------------------------------------
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
(512) 657 8360                    
--------------------------------------------------------

Attachment: sample.xml
Description: sample.xml

Attachment: SPMLProposal.ppt
Description: SPMLProposal.ppt