RE: [provision] SPML - extending SAML and DSML

[Jeff Bohren <jbohren@opennetwork.com>]

A couple of comments:

1) In this example the XML Element Attributes for spml:PSU-AttributeSet
and spml:PSTD should be XML elements so that they can be multi-valued.
This is how both SAML and DSML represent attributes.

2) I'm not sure that the saml:Conditions element has any use in SPML.
This make sense in terms of the SAML Web SSO Profiles since the
assertions are passed indirectly from system to system by a third part
(either as an artifact on an URL or as post data). We don't have a use
case like this in SPML.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 

-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com] 
Sent: Sunday, August 18, 2002 10:39 PM
To: provision@lists.oasis-open.org
Subject: [provision] SPML - extending SAML and DSML

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                    
--------------------------------------------------------