[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 see your point here. I would point out that your key observation is more narrowly scoped than the ballot text: >>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. >> Basically, as I understand it, we should be able to package one (or many???) fragments of XML within a SAML assertion, with the understanding that the fragments extend the information content of the assertion in some standard way. I have no issue with this except that I dont view this as a general enveloping strategy. What I want to stay away from is a general SAML packaging framework. - prateek >>-----Original Message----- >>From: Evan Prodromou [mailto:evan@outlook.net] >>Sent: Tuesday, March 27, 2001 7:11 PM >>To: security-use@lists.oasis-open.org >>Subject: Re: my ballot for GROUPS 6, 7, 8, 9 >> >> >>>>>>> "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|)"|#.=JC648WQ >>DJO5^+.-! >> >>]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 >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC