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: my ballot for GROUPS 6, 7, 8, 9

I'm not caught up on the last day's worth of postings, but Evan's comments 
here seem to point up the difference I recently posited between generic 
mixed-semantics XML documents (using XML namespaces) and true envelopment 
(which implies a more complex model of wrapping/stripping and processor 
handoffs).  I think we have to expect that places in the SAML vocabulary 
will allow extensions, probably by means of ##any or similar in XML 
Schema.  However, this is still not going as far as making the SAML part a 
"wrapper" for the color information; the color information is an adjunct to 
the security information that is the main goal of the message.


At 04:10 PM 3/27/01 -0800, Evan Prodromou wrote:
> >>>>> "MP" == Mishra, Prateek <pmishra@netegrity.com> writes:
>     MP> Some care is needed on this issue. Are we proposing to build a
>     MP> general packaging infra-structure so SAML can "enclose"
>     MP> arbitrary XML payloads?? To me that seems to be far beyond the
>     MP> scope (and resources) of this group.
>I disagree about the difficulty of implementing this. It seems that
><extension> types, as used in AuthXML, would be totally sufficient for
>enveloping data.
>For example, take this hypothetical message for requesting
>authorization to use a resource (push model SSO), which includes some
>info about the user's current color preferences in an Extension:
>         <HypotheticalAuthZRequestMessage>
>            <AuthNDataPlusAuthZAttributes>
>            [...]
>            </AuthNDataPlusAuthZAttributes>
>            [...Other SAML Message Stuff...]
>            <Extension xmlns:prefs="blahblahblah">
>              <prefs:BackgroundColor>lime green</prefs:BackgroundColor>
>            </Extension>
>         </HypotheticalAuthZRequestMessage>
>Here, the request message envelopes data from another namespace,
>fairly straightforwardly. Without this kind of piggybacking, the data
>is going to have to be sent through another (probably custom)
>protocol, with some kind of reference to the identity of the
>Similarly, data could be attached to an assertion, like:
>         <AuthNDataPlusAuthZAttributes>
>           <Name>Evan</Name>
>           <Rank>...</Rank>
>           <SerialNumber>0</SerialNumber>
>           <Extension xmlns:xface="blahblahandalsoblah">
>           <xface:data>
>              O]e/
>           </xface:data>
>           </Extension>
>         </AuthNDataPlusAuthZAttributes>
>Here, the assertion of the subject's identity is accompanied by a
>tiny, low-res, grainy picture of subject according to the X-Face
>I think for SAML to be extensible at all, it's going to need to have
>extension items. And if it has extension items, we can do enveloping.
>There is, of course, a conceptual difference between an extension to
>the SAML standard and a payload orthogonal to security
>issues. However, it seems to me that the same mechanism can be used to
>provide both types of functionality. (With later versions of AuthXML,
>a flag was added to an extension to indicate if the extension was
>crucial to the surrounding element, or could be ignored.)
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: security-use-request@lists.oasis-open.org

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

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

Powered by eList eXpress LLC