Re: my ballot for GROUPS 6, 7, 8, 9

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

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.

         Eve

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
>subject.
>
>Similarly, data could be attached to an assertion, like:
>
>         <AuthNDataPlusAuthZAttributes>
>           <Name>Evan</Name>
>           <Rank>...</Rank>
>           <SerialNumber>0</SerialNumber>
>           <Extension xmlns:xface="blahblahandalsoblah">
>           <xface:data>
> 
>,g%"s<[u6Q6D*^>I)#,vi>V"A^D?MvkJMqVf]W]CHsD*{DdN|)"|#.=JC648WQDJO5^+.-!
> 
>]5Ff;$uEOKPq2CjF:?";[Hn=pjFzy!R5he8;Gq&~Rp9^R4\="q@~95,u`N2Mst@;/Ie1nJ,0+FyA>T
> 
>CO\<%I%)A0g|J\9#:/]v{9X-Ab\bA[zi*^L}]?=jM,hn18^FqA}IRw+O9z]bFZ%pkySg#Z{E6}7R<o
>              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
>standard.
>
>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.)
>
>~ESP
>
>
>
>
>
>------------------------------------------------------------------
>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