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

I've added this as Last Call comment LC-2721, see https://www.w3.org/2006/02/lc-comments-tracker/42458/WD-xmldsig-core1-20121018/2721 in tracker.

Note that this comment applies to 2nd edition REC and 1.1. It is not a comment on changes introduced for this latest Last Call.

That said, can members of the WG please review and comment/suggest concrete resolutions to the issue?

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Nov 2, 2012, at 12:06 PM, ext edsimon@xmlsec.com wrote:

> I'm resending this, as plain text, because the Web archive doesn't seem
> to have stored the message properly...
> 
> -------- Original Message --------
> Subject: Fwd: Comment for XML Signature Syntax and Processing Version
> 1.1 Working Draft 18 October 2012 (re: here() function)
> From: <edsimon@xmlsec.com>
> Date: Fri, November 02, 2012 12:01 pm
> To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>,
> public-xmlsec@w3.org
> 
> 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>
> Date: Wed, October 31, 2012 7:00 pm
> To: <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
> 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 Thursday, 8 November 2012 18:36:47 UTC