RE: [provision] Provisioning Modeled as an Assertion Application

[Jeff Bohren <jbohren@opennetwork.com>]

I agree that you could reuse parts of SAML even using the
request/response model, but what value does that add? Assuming we want
to use the attribute to represent provisioning data, how good of a fit
is it? Looking at our use cases:

Use case 1, 2, 5, 6, 8, 9 - These are all creation requests. The data
could be represented as a SAML assertion, but that adds no value over
DSML V2 or other existing XML protocols that support attribute value
sets.

Use case 3, 7, 10 - These are all modify requests. Assertions are not a
good fit for this because they describe what the state is, not what
changes are needed. How do you remove an attribute using an assertion?
The DSML V2 model supports this directly. There are probably other XML
protocols that support this directly as well.

Use case 4, 11 - These are all delete operations. Assertions add no
value here.

Use case 12 through 17 are all communication use cases and are not
relevant to this discussion.

So we can, in some of our use cases, represent the data in SAML, but
why? I hate to keep harping on this, but if it only supports about half
of our request use cases, why are we still considering it? 

I'm really not trying to compare it to DSML, I still don't see a value
over not reusing anything. From what I've seen at this point I don't see
that it adds enough value to be worth the effort of figuring out how to
select what parts of SAML to use and what not. Not to mention the
philosophical debates on how one should go about extending schemas.

If we are not using the envelop parts of SAML because they don't fit our
request/response model, and the assertion part only fits the create use
cases, what's left?


Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 

-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com] 
Sent: Wednesday, August 21, 2002 12:54 PM
To: Jeff Bohren; provision@lists.oasis-open.org
Subject: RE: [provision] Provisioning Modeled as an Assertion
Application

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