OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

I am equally far behing on my email.

The XMLdsig term Eve is looking for is "detached signature."


> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Monday, March 26, 2001 10:38 AM
> To: security-use@lists.oasis-open.org
> Subject: RE: ISSUE:[UC-7-0{1|2}:Enveloping]
> 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 
> >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
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-use-request@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC