RE: ISSUE:[UC-7-0{1|2}:Enveloping]

["Eve L. Maler" <eve.maler@east.sun.com>]

I'm going to try to respond to Dave since he mentions some of our shared 
experience in standards work.  (I'm not sure if you folks are completely 
past this topic by now; apologies if you are.)

Dave's observations about XLink and XInclude are interesting.  And I agree 
that ideally "there can be only one" design choice here.  (I'm a Highlander 
fan!)  However, I think it's possible to draw too strong an analogy between 
these other applications and SAML.

It's correct that XLink (http://www.w3.org/TR/xlink) is "enveloped."  The 
details of whether it uses attribute or element syntax don't matter as much 
as the fact that you embed XLink links into documents, where they are left 
to be discovered among the other various semantics.  At least when it comes 
to simple hyperlinks, it could be no other way because simple linking is 
point-to-point, and the starting point is *inside* a resource 
somewhere.  (BTW, we've labored mightily to avoid specifying a processing 
model for XLink, but this worked against us, IMHO.)

XInclude (http://www.w3.org/TR/xinclude) is also enveloped, again because 
it is embedded in a document.  It has a very precise processing model, 
although it doesn't so much require a "choreography" as a static 
description of transformation start and end states.

The way that the applications are supposed to communicate when faced with 
mixed-semantics messages/documents is by means of namespaces.  This is how 
XLink and XInclude are presumed to work: Processing gets spun out to 
whatever application understands namespace X, whenever a markup construct 
of namespace X is discovered.  Schemas govern how namespaces are allowed to 
be mixed, so that you're constraining the input to your processor 
appropriately.

But mixed semantics are the general case, and envelopment seems to be the 
special case:

   wrapper B (in namespace B)
     wrapper A (in namespace A)
       payload (in namespace P)
     /wrapper A
   /wrapper B

With envelopment (no matter whether SAML is B, A, or P), I think we're 
assuming that each layer of wrapper is a "protocol layer" that has to be 
stripped by a special processor before being passed down the line.  To 
processor B, everything from wrapper A inwards is considered the payload 
(and so on for every additional wrapper).

At the actual SAML level (apart from the bindings), my intuition says to 
avoid the wrapping/stripping scenario if we can.  It complicates things 
because processing now depends on what processors have been "visited" along 
the way.  I'd rather specify changes "statically" a la XInclude, by 
describing the transformations a SAML message is allowed to undergo and by 
what "agent."  (Maybe this is saying the same thing as Dave is advocating; 
I'm not sure.)

I would call this third choice, between enveloped and enveloping, 
"standalone."  I'm not sure what a SAML message would actually envelop 
anyway: the resource to which access is requested??  Is any particular use 
case, e.g. B2B, truly helped if you allow envelopment of something not 
directly related to security communications?

So my intuition is to make SAML messages standalone.  They should have one 
purpose (security communication) only, and not try to wrap or be wrapped by 
"real" resources that they're related to.  "Mixed semantics" should only 
enter the picture when an embedded bit of security-related information 
(e.g., XACML or something) is not native to SAML but rather is farmed out 
to other vocabularies in service of extensibility and modularity.

Now I've exposed another layer of my ignorance...

         Eve

At 03:53 PM 3/22/01 -0500, Orchard, David wrote:
>I've spent a good amount of time thinking about the envelope/enveloping
>issues.  Eve and I worked on XLink and XInclude which has gone through a
>somewhat similar analysis.   The following lengthy treatise illustrates my
>rationale behind my voting.
>
>First thing to do is to look at characterising the differences in the
>approaches and the ramifications.
>
>Enveloping is where the top level construct of a message is a SAML
>construct, ie a SOAP 1.1 document.  SAML must then define the
>dance/choreography of these messages.  Hence a bindings and a protocol are
>required for SAML.  If there is no enveloping requirement, then the
>protocols and bindings sections of SAML disappear.
>
>Enveloped is where the top level construct is a non-SAML construct, ie a
>CommerceOne business document.  In this case the dance of messages and the
>bindings to other protocols is defined outside  the scope of SAML so SAML
>only defines assertions.
>
>These discussions very much remind me of XLink, XInclude and Java O-O
>practices.  Allow me to illustrate: XLink and XInclude both had the choice
>of specifying
>o an element based syntax, ie <xi:include href="xyz.html"/>
>o an attribute based syntax, ie <myNS:myElem href="xyz.html"/> where myElem
>was defined to be of "type" XInclude
>
>It turns out that XLink decided on an attribute based syntax to enable other
>vocabularies to re-use the attribute definitins.  XLink is very much a data
>format and not a processing model (ie protocol).  XInclude flip-flopped from
>element to atribute to element syntax.  The decision seemed to favour
>element syntax because there was a processing model for XInclude and so it
>needed to be able to stand alone.  We didn't want every potential consumer
>to have to create their own elements based upon XInclude.
>
>The issues around extensibility of element/attribute based syntax are pretty
>similar to enveloping/enveloped requirements, particularly around fitting
>into other vocabularies.   In particular, XInclude has had to deal with
>whether or not/where to allow other vocabularies to extend it's syntax (same
>as enveloped), and XLink has had to deal with conformance of vocabularies
>that use it's syntax.
>
>One VERY important standards goal that we have not talked about much is that
>minimalism is good.  Therefore it is probable that choosing BOTH enveloped
>and enveloping is a bad design.  We should probably choose one.  XLink and
>XInclude both decided that they could not support both syntaxes.
>
>So I ask myself which should I choose?  Are we creating a data model or a
>processing model?  It seems we have both.  The SSO use case implies a
>processing model, whereas the intermediaries/B2B use case implies a data
>model.
>
>Now I fully realize that the processing model requires a data model.  The
>issue is that if you vote for both, it seems that we cannot say an
>implementation is SAML compliant if it ONLY supports the data model.  It has
>to support the higher construct (protocol) to be SAML compliant.
>
>I tried to think about how this would get used in a real world application.
>There are 2 different application models that I see.
>1. Enveloping yields an application architecture that has a SAML application
>recieving the first request.  So how would an application "register"
>interest in the non-SAML bits of the message?  Seems like this could be very
>complicated, like a servlet/ejb programming model.  There would have to be
>some way of defining an interface/programming model between the SAML app and
>the non-SAML app.  Presumably this would be more complicated than SAX/XSLT
>pattern matches.  I've spent a LOT of time dealing with server-side
>programming models, and this one seams really hairy about how to register
>interest in a part of a message, and then have it sent to the app.
>
>I guess the alternative is that the entire SAML request is passed to the
>next application, but that means that every application downstream must be
>"aware" of SAML aspects.
>
>2. Enveloped yields an architecture that has a non-SAML app recieving the
>first request, then passing the SAML portion or entire request to a SAML
>application.  Then SAML application presumably validates the SAML portion,
>returning true/false.  So how does the SAML app know "where" in the message
>the SAML bits are?  The app would have to register the places that
>assertions could occur, perhaps XPath expressions.  Or I guess that app
>could do some XPath search to discover all the assertions, but run-time
>discovery seems inappropriate to me.
>
>I am having difficulties with this because I have never dealt with an open
>data format that mixes security information with application information in
>a multi-hop messaging environment.  I have tried to think about how other
>message based systems dealt with it, but my MQ experience didn't yield
>anything useful because MQ doesn't have an open data format, nor did it
>genericly solve the problem of "who's on top".  Thinking about object
>systems like EJBs/RMI/ didn't help me, though I hear we have a corba
>security expert on the staff.
>
>Now I don't know which architecture is the one (highlander principle) that
>we should target for SAML.  This seems like it needs more exploration and
>discussion.  Perhaps an expected system architecture section in the SAML
>domain model would illustrate how we see the architecture being used.  I
>would really like to hear from the security experts who have built security
>in cross-domain messaging systems on their experience in this.
>
>After all this, I'm leaning towards voting for enveloping (then it can be
>standalone) and against enveloped, knowing that this means some of the B2B
>cases can't be met by SAML directly.  I would see a B2B vocabulary using the
>SAML assertion point, but it wouldn't be described as a "SAML" application,
>nor would it be SAML conformant.

--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com