Re: [security-services] In defence of XPath

[Cameron Morris <cmorris@novell.com>]

On Thu, 2005-06-02 at 15:17 -0400, Conor P. Cahill wrote:
> 

> Let's use a real example as that seems way to contrived for
> me as some set of name-value pairs that wouldn't be a typical
> XML document for data.  How about we have a document like:
> 
> <profile>
>     <name lastUpdate="10/1/03">Conor</name>
>     <address>
>         <addr1>10 main street</addr1>
>         <addr2>apt. 999 </addr2>
>         <city>somewhere</city>
>         <st>SP</st>
>         <zip>99999</zip>
>     </address>
>     <phone class="home">999-999-9999</phone>
>     <phone class="cell">888-888-8888</cell>
> </profile>
> 
> 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>


Thank you Conor, that is much more clear now.  This looks very similar
to what Arnaud Sahuguet of Lucent proposed back in earlier discussions
through using xSquirrel:
http://lists.oasis-open.org/archives/security-services/200504/msg00025.html
I responded that I really am after the individual elements of the
document:
http://lists.oasis-open.org/archives/security-services/200504/msg00049.html


Now that I understand, I have a few issues with the proposal:
1) I really am after the text nodes because this is most interoperable.
Imagine a liberty and saml enabled IDP in which users' data are stored
in liberty services (Employee and personal profile).  Now imagine that
IDP wishes to inter-operate with a pure SAML(2.0) service provider.  The
SP knows nothing about liberty services, nor implements anything
remotely close for user attributes.  The SP will likely having a mapping
service to map IDP attributes into a native, understandable name.  It is
much easier to map text attributes (text nodes of the liberty service
document) than parsing/interpreting the xml formatted attribute value
for the desired attributes.

Again, note that the current proposal does not preclude the SP from
querying and obtaining rich XML content, including element attributes,
or the entire document (Such as //PP:pp)

2) There can exist naming conflicts in caches.  Using the example above
suppose an SP queries for the Name element and caches the result.  The
name of the asserted attribute will be "profile".  Later the SP requests
the phone attribute, which will result in an assertion attribute named
"profile".  So what should the cache do assume that the value was
changed and replace the value for Name with Phone, or should it
correctly merge the two attributes.  The later would be correct behavior
but I doubt anyone has implemented anything close - I have not.  

3) An IDP may not have the document local. A personal or employee
profile can reside at another federated service provider.  I suppose
this may not be such a big deal, since the XML structure could be
recreated using the XPath query.  However, if I need to reconstruct the 

I've responsed below to the issues you raised:
> The differences (and, I believe, advantages of the
> first proposal above) are:
> 
>     * The data within the <AttributeValue> container is
>       in the *exact* format one would expect from interacting
>       with the service.  With the Xpath solution, the
>       recipient must put together the xpath data plus the
>       data within the Attribute value to essentially
>       reverse engineer the document structure -- and to fully
>       understand the element you have to understand the
>       placement of the element within the document structure.
I disagree, simply because the standard response I would get from a
Liberty Service would not be in the format you propose.  (Again I could
synthesis the result to match your proposal using the original xpath
query, but what's the point)

I agree that knowing the document structure is an issue for the SP.  For
this situation the IDP will advertise in metadata the supported or
common xPath attributes, so that the SP does not have to know the
structure of the document.  

>     * Attributes on elements within the source document are
>       not easily handled (as far as I can tell) with the
>       proposed solution (where does the lastUpdate attribute
>       end up for the name element, likewise the class for the
>       phone element.
an attribute XPath query of //Profile/name results in
<Attribute name="//Profile/name">
 <AttributeValue><name lastUpdate="10/1/03">Conor</name>
 </AttributeValue></Attribute>

Only in the case of //Profile/name/text() does the attribute get dropped
> 

>     * the xpath solution assumes that the source document is
>       xpath addressable (that that's the structure used by
>       the service) and locks itself to that type of service
I agree