RE: [provision] Provisioning Modeled as an Assertion Application

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

Comments in line.

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


> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Wednesday, August 21, 2002 6: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.

[Comment: Darran Rolls] 
I don't believe that re-using the SAML framework means changing our
model at all. In fact, if re-using elements of the SAML framework does
imply changing the provisioning model, I agree with you completely, the
cost would out weigh the benefits.  I'm fully open to be convinced
otherwise, but I don't see that expressing SPML C.R.U.D operations as a
set of <Statements> changes the model, just the vehicle for expressing
it.
 
> 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.

[Comment: Darran Rolls] 
I don't feel the committee really gave your DSML proposal a full swing
of the bat, nor did we draw any firm conclusions, we should continue to
do that in parallel.

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

[Comment: Darran Rolls] 
IMO the perceived value of building on SAML in the manor proposed is the
re-use of the "out of band" exchange model between the source &
destination sites defined in the browser SSO profile.  

Generally, I have considered the security we "inherit" to primarily be
in the areas of signature, encryption and SOAP bindings.  

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

[Comment: Darran Rolls] 
Agreed.  We could adopt this directly from WSS rather than SAML.

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

[Comment: Darran Rolls] 
I'm not sure I completely understand how the SAML proposal changes our
use cases or the general purpose of our effort...  I think you pretty
much summed it up when you said that the SAML proposal felt more like a
binding than a model.  I whole heartedly agree with this.  The bulk of
our work is in defining the operations and PSTD schema
discovery/definition.  Once we have done that the SAML proposal becomes
more succinct, "can we express this information as SAML <Statements>.