[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] In defence of XPath
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]