- From: Sean Mullan <sean.mullan@oracle.com>
- Date: Fri, 2 Nov 2012 12:24:51 -0700 (PDT)
- To: "Cantor, Scott" <cantor.2@osu.edu>
- Cc: "edsimon@xmlsec.com" <edsimon@xmlsec.com>, "G. Ken Holman" <gkholman@cranesoftwrights.com>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
On 11/02/2012 03:10 PM, Cantor, Scott wrote: > On 11/2/12 3:02 PM, "Sean Mullan" <sean.mullan@oracle.com> wrote: > >> 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. > > This sentence in the response seems unsupportable in aa typical > implementation, I would think: > > "If other functions were available and were used during signing, then > there would be interoperability problems during validation, so no other > functions are allowed in the evaluation context." > > That sounds like a dubious constraint to expect to be in place using off > the shelf components. But I'll defer to the experts. Yes, I guess technically the response might be correct, but when you are trying to build a DSig implementation with reusable parts such as JAXP, it doesn't work, in particular the XPathFunctionResolver [1] interface of the JAXP XPath API cannot be used to directly implement that functionality, because it requires it to be namespace qualified. --Sean [1] http://docs.oracle.com/javase/7/docs/api/javax/xml/xpath/XPathFunctionResolver.html
Received on Friday, 2 November 2012 19:28:04 UTC