OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XPath issues and resolutions


I'm looking for some more feedback on recent changes to the XPath attribute profile:
http://www.oasis-open.org/apps/org/workgroup/security/download.php/12486/sstc-saml-2.0-xpath-attribute-profile-draft-02.pdf
http://www.oasis-open.org/apps/org/workgroup/security/download.php/12484/sstc-saml-2.0-xpath-attribute-profile-draft-02.sxw
 
Several issues with an XPath attribute profile were discussed with previous revisions.  To make sure these are resolved I thought I'd make a compilation of the issues and where I think they are at currently.  
 
Here is a link for the use cases to get a feel for goals of the profile: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00044.html
 
Issue: Liberty's defined minimum subsets usually reference elements and not text nodes.  Yet, the use cases show that we are really after the text nodes
From: Robert Aarts
Email: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00071.html
Implementations now must support at a minimum absolute xpaths to text nodes.  This means appending "/text()" to the defined Liberty xpaths.
 
Issue: Uniquely referencing attribute values with XPath - useful for caching
From: Anne Anderson
http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00023.html
This is still a concern.  We don't want attribute consumers to have to know that much about the XML document.  To the SP an xpath attribute should be just like any other attribute.  If IDP's and SP's stick to the defined interoperable subset (absolute paths to text nodes) then caching should be OK.  There still can be some duplication of data inside the cache - but it shouldn't ever have incorrect data.  However, by not solving this problem we solve the next few issues.
 
Issue: Use only uniquely identifying xpaths for asserted attributes but full xpath in queries.  This could result in multiple attributes(not just multiple values) returned for one attribute query
From: Scott Cantor, Anne Anderson
http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00034.html
This goes away if we relax the need for asserted attributes to by absolutely unique.  
 
Issue: Trying to use XPath in the name with 'urn' name format
From: Eve Maler, John Kemp, Robert Aarts, Rich Salz...
email: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00067.html
http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00054.html
http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00060.html
http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200504/msg00057.html
... and others
The name format is now w3.org's URL for XPATH and the name is straight XPATH.  If we do not need unique xpaths then we don't have to state which xpath restriction we are using.
 
Thanks,
Cameron Morris


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]