Action-565: Visible Utilization in XPath

Regarding my Action-565, I developed some preliminary approaches, but
all of these have their drawbacks:

*Approach #1: XPath-driven QName search.*

The idea is to search the XPath contents of "IncludedXPath" and
"ExcludedXPath" for occurrences of QNames. Every QName found implies
considering its prefix as "visibly utilized", hence having its namespace
declaration put to the "IncludedXPath" or "ExcludedXPath" element,
respectively.
The search can either be XPath-aware (i.e. occurrences of prefix-like
syntax in fixed string-type XPath tokens are not considered) or
XPath-unaware (simple search for ":", consider everything before to be a
prefix => visibly utilized.)

Example:

/a:X [//b:Y/child::text() = 'c:\\myUSB']

XPath-aware mode will identify prefixes "a" and "b".
XPath-unaware mode will identify prefixes "a", "b", "child" and "c", at
best. May even find "[//b" and the like if implemented stupid enough.

Drawbacks:
XPath-aware is the only reasonable behaviour, but requires close
integration with XPath parsing => no standard XPath lib applicable.
XPath-unaware is much easier to implement (String ops only), but may
find more prefixes than actually are present (which is no problem) and
may even fail to find others (ok, only in most stupid implementation mode)

*Approach #2: Document-driven QName search.*

This approach consists in searching the whole document of interest for
occurrences of prefixed elements, collecting all prefixes that are
actually used in elements or attributes. Then, this list is matched with
the XPath expressions from "IncludedXPath" and "ExcludedXPath", to see
whether some of the prefixes occur within the XPath expressions. As
above, this can be done either XPath-aware or XPath-unaware, with the
same implications to complexity and stupid behaviour.

*Approach #3: prohibit QNames in XPath*

Instead of using QNames in XPath, we force the XPath expressions not to
contain any QNames. For namespace-free documents this means no change,
for namespace-aware documents this requires sth. like putting
"/*[local-name()='Body' and
namespace-uri()='http://www.w3.org/2003/05/soap-envelope']"
instead of
"/soap:Body".

Drawbacks:
High threat of developers to screw it up.

*Approach #4: listing used QNames explicitly*

On signature generation, when defining the XPath expressions for the
signature reference, this approach requires an explicit statement
listing all QNames used in the XPath as part of its definition.

Example:

<IncludedXPath QNames="soap:Body
my:Node">//soap:Body/my:Node</IncludedXPath>

Drawbacks:
Requires changes to XML Signature 2.0 syntax, threat of forgetting
used/adding unused QNames.
Puts additional tasks to the signature generator.
Somewhat redundant information.

*Approach #5: Abandon XPath*

Abandon XPath compatibility for the sake of a similar but QName-aware
syntax. Signature generators may choose style, depeding on validators'
capabilities/expectations.

Examples:

//{http://www.w3.org/2003/05/soap-envelope}:Body
//soap:Body
//{http://www.w3.org/2003/05/soap-envelope}[soap]:Body

Drawbacks:
Syntax has to be defined.
Syntax has to be accepted/used.
Syntax must be implemented.
Still people can screw it up.


Note that these approaches are developed for the XPath use case only. If
QNames happen to occur in other text contents, they may not be applicable.

I don't claim this list of approaches to be complete nor desirable, but
I fear we don't have many alternatives.

Feedback would be appreciated.

best regards

Meiko

-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. IC 4/150
D-44780 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de

Received on Monday, 10 May 2010 13:19:56 UTC