[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 --------------------------------------------------------
Attachment:
sample.xml
Description: sample.xml
Attachment:
SPMLProposal.ppt
Description: SPMLProposal.ppt
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC