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

[Darren Platt <dplatt@securant.com>]

It seems to me that the question here is essentially whether the extensions
included in the SAML document should be secured the same way as the elements
defined by SAML.  I believe the SAML message handlers should secure the
extensions that are included within the SAML assertion document.

Regards,

Darren



> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Wednesday, March 28, 2001 10:19 AM
> To: security-use@lists.oasis-open.org
> 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%pk
> ySg#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
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: security-use-request@lists.oasis-open.org
>