RE: Action-565: Visible Utilization in XPath

Also related to ACTION-658

Here is a proposal to scan the XPath to look for prefixes.

First of all prefixes can never be inside a double string or somehow computed. I.e. you can do something this
/../*[local-name() = "chapter"]      Find out all elements anywhere in the tree whose local name is "chapter"

But you cannot do
/../*[prefix() = "xenc"]    Find out all elements whose prefix is "xenc"

I.e. you cannot programmatically search for prefixes, you can only do expressions with namespace URIs. Prefixes can only be used directly in the expression.
So basically you can ignore all double quoted strings when searching for prefixes.  Based on this here is a very simple approach to scan for prefixes

1. First remove all double quoted and single quoted strings.   
  s/"[^"]*"//g
  s/'[^']*'//g

A double quoted string starts with double quote, and ends at the next double quote. If a double quote needs to present in the string, it should be specified as "  By removing the quoted string we remove false positives that would be generated when colon characters are used inside strings.

2. In the resultant string search for single colons and get the word just before colon

 m/([\w-:]+)?\s*:(?!:)/


Pratik

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, May 11, 2010 8:26 AM
To: Meiko Jensen; XMLSec WG Public List
Subject: RE: Action-565: Visible Utilization in XPath

> *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.

This is the one that I think should be recommended but not required. QNames
in content are simply bad things. We know that now, and the remanining uses
of them are from specs that predate that knowledge. Which is life. But where
there are alternatives that allow the same functionality without using them,
we would be crazy IMHO not to bless those approaches as being better for use
with signatures.

Developers will screw up anything and everything, and that's also just life.
That shouldn't prevent us from documenting workarounds that actually *solve*
this problem. It's quite rare in these cases for such solutions to actually
exist at all.

> *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.

I think this one is also worth considering, because changing the syntax is
not a drawback at this point (we're in draft) and because it's likely that
the creator of the XPath expression is in a good position to know what
QNames are actually being used, seems to me.

-- Scott

Received on Monday, 11 October 2010 19:48:45 UTC