[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."
Hal
> -----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
> 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
>
>
> ------------------------------------------------------------------
> 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