Re: Fwd: Comment for XML Signature Syntax and Processing Version 1.1 Working Draft 18 October 2012 (re: here() function)

Hmm, I knew this issue looked familiar. I actually reported this as an 
issue way back in 2004 and here was the explanation:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2004JanMar/0057.html

I'm still not sure what the right answer is.

--Sean

On 11/02/2012 12:01 PM, edsimon@xmlsec.com wrote:
> G. Ken Holman of Crane Softwrights (copied) has noticed an issue
> (detailed below in Ken's email) with the definition of the here()
> function in XML Signature. After Ken brought this to my attention, I
> have been wondering if the namespace injection/wrapping issue [1] [2]
> that Meiko and I investigated might be applicable to this issue (and
> thus make it more important than just a "function not found" problem).
>
> Ed
>
> [1] http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0000.html
>
> [2] http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0005.html
>
>     -------- Original Message --------
>     Subject: Comment for XML Signature Syntax and Processing Version 1.1
>     Working Draft 18 October 2012
>     From: "G. Ken Holman" <gkholman@CraneSoftwrights.com
>     <mailto:gkholman@CraneSoftwrights.com>>
>     Date: Wed, October 31, 2012 7:00 pm
>     To: <edsimon@xmlsec.com <mailto:edsimon@xmlsec.com>>
>     ...
>
>     Attn: Editors of XML Signature Syntax and Processing Version 1.1
>     Re: Working Draft 18 October 2012
>
>     Since version 1 of XML Signature there has been a glaring (to me)
>     error in the specification of the "here()" function, in that it was
>     never properly named using a namespace qualification.
>
>     Languages that use XPath typically assume that unprefixed function
>     names are functions in the XPath library and that functions outside
>     of the XPath library must be prefixed with a namespace qualification
>     of some kind. Certainly XSLT and XQuery impose this
>     constraint. Indirectly so does Schematron. Such a constraint has
>     not been a part of XMLSec.
>
>     The (low probability) issue is that who knows what future versions of
>     XPath might include in a function named "here" of its own? It would
>     be unavailable to users of XMLSec (or, worse, implement some
>     unexpected future semantic).
>
>     The (guaranteed probability) issue is that a general-purpose XPath
>     analyzer looking at the expression would flag the "here()" as a
>     syntax error because the unprefixed function is not part of the
>     standard library.
>
>     Standalone XPath processors may soon be available. Implementers of
>     XMLSec who want to use such a processor are going to be challenged
>     since the expression will trigger "function not found" errors when
>     analyzed.
>
>     But I acknowledge that there is already an established base of using
>     "here()" with XML Signature 1.0.
>
>     My thought is that "here()" could continue to be allowed for backward
>     compatibility, but would be deprecated from now on in favour of
>     something like "ds:here()" (where, of course, the prefix is
>     irrelevant but it is mapped to the signature namespace).
>
>     Then, a general-purpose XPath processor would look for the function
>     named "{http://www.w3.org/2000/09/xmldsig#}here()" in the set of
>     statically-defined function signatures provided by the application
>     invoking the XPath processor:
>
>     http://www.w3.org/TR/2007/REC-xpath20-20070123/#static_context
>     [Definition: The static context of an expression is the information
>     that is available during static analysis of the expression, prior to
>     its evaluation.] This information can be used to decide whether the
>     expression contains a static error. If analysis of an expression
>     relies on some component of the static context that has not been
>     assigned a value, a static error is raised [err:XPST0001].
>
>     http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-function-signature
>     [Definition: Function signatures. This component defines the set of
>     functions that are available to be called from within an expression.
>     Each function is uniquely identified by its expanded QName and its
>     arity (number of parameters).] In addition to the name and arity,
>     each function signature specifies the static types of the function
>     parameters and result.
>
>     http://www.w3.org/TR/2007/REC-xpath20-20070123/#id-function-calls
>     [Definition: The built-in functions supported by XPath are defined in
>     [XQuery 1.0 and XPath 2.0 Functions and Operators].] Additional
>     functions may be provided in the static context. XPath per se does
>     not provide a way to declare functions, but a host language may
>     provide such a mechanism.
>     ...
>     A function call consists of a QName followed by a parenthesized list
>     of zero or more expressions, called arguments. If the QName in the
>     function call has no namespace prefix, it is considered to be in the
>     default function namespace.
>
>     http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-def-fn-ns
>     [Definition: Default function namespace. This is a namespace URI or
>     "none". The namespace URI, if present, is used for any unprefixed
>     QName appearing in a position where a function name is expected.]
>
>     Having the function name namespace qualified would allow the
>     expression to be rewritten in an XPath context without having first
>     to inspect the expression for the errant (to the XPath processor)
>     "{}here()" syntax. As it stands today, there is a burden on
>     implementation to prevent the "{}here()" function from getting to an
>     XPath library written as it is for fear of triggering a static error
>     "err:XPST0001".
>
>     I hope this is helpful.
>
>     G. Ken Holman
>     gkholman@CraneSoftwrights.com <mailto:gkholman@CraneSoftwrights.com>
>     http://www.CraneSoftwrights.com/bio
>
>     --
>     Contact us for world-wide XML consulting and instructor-led training
>     Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
>     Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/
>     G. Ken Holman mailto:gkholman@CraneSoftwrights.com
>     Google+ profile: https://plus.google.com/116832879756988317389/about
>     Legal business disclaimers: http://www.CraneSoftwrights.com/legal
>

Received on Friday, 2 November 2012 19:05:57 UTC