RE: [security-services] In defence of XPath

["Scott Cantor" <cantor.2@osu.edu>]

> To reeturn the name and phone numbers with an assertion, I
> propose we include the following as an attribute statement:
> 
> <Attribute name="profile" ... >
>      <AttributeValue>
>     <profile>
>         <name lastUpdate="10/1/03">Conor</name>
>         <phone class="home">999-999-9999</phone>
>         <phone class="cell">888-888-8888</cell>
>     </profile>
>      </AttributeValue>
> </Attribute>

I think with respect to returning an entire XML "record", one use case I've
looked at in the past being IMS learner information profile records
(www.imsproject.org), this is the right approach.

But if you're talking about individual fields in the "record", it's just not
consistent with at least our uses of attributes to be lumping all kinds of
data into a single attribute named "profile" (or whatever name is used).

I rather like the fact that the Xpath model lets a record be accessed and
encoded with multiple levels of granularity, including full XML or simple
text.

Of course, I *don't* like the fact that the attribute's "name" isn't really
a name but a location in a document, but it's not the first time the same
data element ended up with multiple names and won't be the last.

So what you see as a disadvantage, I think I see as the entire point.

We definitely don't need a profile to just send XML blobs as attributes. I'd
actually argue to some extent that the entire point of attribute profiles is
to construct scenarios in which complex XML can be sent as something simpler
than XML so that when apps consume the SAML, the SAML processor can provide
simpler data. Because to put it bluntly, XML sucks for application
developers. They hate it. The ones working in my building tell me so
routinely and loudly.

-- Scott