- From: <Frederick.Hirsch@nokia.com>
- Date: Mon, 5 Nov 2012 11:19:45 +0000
- To: <sean.mullan@oracle.com>
- CC: <Frederick.Hirsch@nokia.com>, <cantor.2@osu.edu>, <edsimon@xmlsec.com>, <gkholman@cranesoftwrights.com>, <public-xmlsec@w3.org>
Does anyone have any concrete suggestions on how to resolve the issue, unless we maintain the original resolution which was accepted at the time? regards, Frederick Frederick Hirsch Nokia On Nov 2, 2012, at 8:24 PM, ext Sean Mullan wrote: > 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 Monday, 5 November 2012 11:20:33 UTC