[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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC