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

[Evan Prodromou <evan@outlook.net>]

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