RE: [provision] Provisioning Modeled as an Assertion Application

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

Firstly, let me state the position of my replies here and my entire SAML
proposal, is not a "lay down in the road" issue for me.  It's simply
something we need to investigate along with the DSML.  Jeff gallantly
championed the DSML discussion; I am merely the designated champion of
the corresponding SAML discussion...

Re 1. It would be a PSTC specification.  If our effort required changes
to the SAML schema (outside changing it through designed extensible
schema points) then yes, those elements would need to be "processed" as
changes with the SSTC.

Re 2.  I would say no, re-using SAML in the way proposed does not move
SPML into an explicit security domain.  I would argue that it is already
part of a model security infrastructure anyway...  That said, IMO we
should consider this re-use proposal just like we do any other form of
"code" re-use.  Consider a SOAP based web service.  It will likely be
bound to the WSS SOAP security specification.  This does not necessary
move the application into the security domain, it simply means it
re-uses and possibly extends it.

Re 3. I guess the qualifier here is the fact that we would simply be
re-using elements of the SAML schema not extending the SAML
specification. I don't see that this should restrict us in any real way.


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


> -----Original Message-----
> From: Yoav Kirsch [mailto:Yoav.Kirsch@businesslayers.com]
> Sent: Wednesday, August 21, 2002 4:16 PM
> To: 'Tony Gullotta '; ''Jeff Bohren' ';
'provision@lists.oasis-open.org '
> Subject: RE: [provision] Provisioning Modeled as an Assertion
Application
> 
>  I agree with Tony, our model should reuse SAML for authentication but
not
> be an extension of SAML.
> Regardless the technical questions there also other question such as
> If we set SPML to be SAML extension then
> 1.	Who should approve the protocol SPML or SAML or both committees
> 2.	Does this implementation move SPML into the security space
rather
> then the application / infrastructure space. And if so do we want move
>  SPML to this space
> 3. Are there any limitation to SAML . For example will we be able to
reuse
> DSML or SOAP if we are using SAMP. ( DSML , SOAP are just examples)
> Yoav Kirsch
> 
> -----Original Message-----
> From: Tony Gullotta
> To: 'Jeff Bohren'; provision@lists.oasis-open.org
> Sent: 8/21/02 1:02 PM
> Subject: RE: [provision] Provisioning Modeled as an Assertion
Application
> 
> I think we are stretching the original intent of SAML by trying to
stuff
> SPML into it. SAML was constructed for authorizing operations, not
> subscribing to services in a more long term fashion. There may be
hooks
> to extend it to do other things, but I bet we can find several other
> protocols that also have extensions that we could shoe horn our stuff
> into.
> 
> I think there is relevance to SAML as a complimentary technology. I
> think the assertion model they have would be great for a PSP to
inquire
> about a subject user of the service in order to make policy decisions.
I
> think the authentication services they have may also provide some use.
> But I believe the actual provisioning requests themselves should be
> defined outside of the SAML framework. I would think DSML would be a
> better fit that SAML, but even DSML I feel falls short of our goals.
> 
> My 2 cents.
> 
> Tony
> 
> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Wednesday, August 21, 2002 4:56 AM
> To: provision@lists.oasis-open.org
> Subject: RE: [provision] Provisioning Modeled as an Assertion
> Application
> 
> 
> 
> As I pointed out in the telcon Mon, this is not really an area of new
> research. Excellent provisioning systems exist today that follow the
> request/response model and work well for customers. Although there are
> plenty of areas that can be improved, the basic model seems to be a
> success. I believe that our goal should be to take that proven model
and
> turn it into an OASIS standard. If we start trying to invent a whole
new
> unproven model as a replacement for something that already works well,
> we are doomed to irrelevance.
> 
> I also question the premise that we must move to an assertion model to
> reuse other standards. While that may be true concerning SAML, it is
not
> true in general. In my "DML Provisioning Proposal" I demonstrated that
> 14 out of 18 of the SPML use cases could be accomplished using DSML
with
> out any modifications to the DSML V2 schema. The remaining 4 use cases
> could be accomplished by adding just one new operation element. Even
if
> DSML V2 is not the solution for SPML, that is still a whole lot more
> reuse than we will ever get with SAML.
> 
> There is one other point I would like to make concerning security. The
> general consensus has been that we are going to base SPML around web
> service. At the very least that will be the first "profile" that we
will
> define. If that consensus has not changed then many of the security
> issues that SAML had to address are not relevant here. Those security
> issue where driven by the fact that there are profiles in which the
SAML
> assertions are passed by an inherently untrusted mechanism (e.g. the
Web
> SSO Post Profile).
> 
> If we still believe that SPML should be based on web services, then
most
> of the security issues around the message itself should be addressed
at
> the web service level (via WS-Security or what ever standard prevails)
> instead of in the SPML message itself.
> 
> Finally we should focus on solving the problem that we have set for
> ourselves, rather than invent a solution and then look for a problem
to
> apply it to. We already have our use cases and implied requirements
from
> them. Unless we believe that those use cases do not reflect the
problem
> we are trying to solve (in which case we should stop now and fix
them),
> then there is no point in pursing an assertion based solution at this
> time. It simply does not match the use cases we have.
> 
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
> 
> 
> -----Original Message-----
> From: Darran Rolls [mailto:Darran.Rolls@waveset.com]
> Sent: Wednesday, August 21, 2002 1:27 AM
> To: provision@lists.oasis-open.org
> Subject: [provision] Provisioning Modeled as an Assertion Application
> 
> All
> 
> In our discussions around basing SPML on the SAML assertion framework,
> we have to clearly address the following question; what is an
assertion
> application and is provisioning such an application?
> 
> Firstly, what is an assertion-based application?  One definition is
"an
> application built around the expression and evaluation of statements".
> I'm interested to know if anyone has a different or more accurate
> definition than this.
> 
> Based on the above, let me take a pass at answering the question, is
> SPML about the evaluation of statements?   At first pass, one might
> conclude no.  The SPML operations defined in the use cases do not feel
> like statements, they feel more like "operations".  However, if one
> considers the question at hand really to be, do we apply a statement
> oriented applications model to SPML in order to gain a "specific
> benefit", one has to more clearly address the trade off between the
cost
> of adopting this shift in thinking against the perceived benefit.
> 
> List of costs (please add/comment)..
> - Accept the basic statement model when native thinking is that we
have
> an operations/execution model
> - Possible lack of clarity to our purpose
> - ???
> 
> List of benefits as (please add/comment)...
> - Re-use if/where possible
> - Leverage security knowledge in current & future SAML specifications
> - ??
> 
> I have asked for an opinion from the Security Joint Committee and
> through that to the SecServices TC.  Their comments will be
interesting
> input to this discussion (but in no way binding in terms of its
> conclusion).  I will forward their reply to the list.
> 
> --------------------------------------------------------
> Darran Rolls                      http://www.waveset.com
> Waveset Technologies Inc          drolls@waveset.com
> (512) 657 8360
> --------------------------------------------------------
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>