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

["Mishra, Prateek" <pmishra@netegrity.com>]

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
>>