I would like to see if we can achieve this streaming hint with forward
By that I mean, we put in the hint in such a place that older
implementations can still verify such a signature by ignoring the hint,
whereas newer implementations can take advantage of this hint and do
If we add a completely new transform, an older implementation will
error out. So how about adding it as a new attribute to an existing
transform? Implementations will probably ignore unknown attributes. Or
maybe add a new transformation parameter?
The main transform that causes all the headaches is the XPath Filter
transform. XPath is too generic, and given an XPath it is hard for an
implementation to figure out what it intends to do. Most of the XPath
expressions that I have seen are very simple, fall into one of the
a) include/exclude elements (and all descendants) whose name is foo
b) include/exclude elements (and all descendants) which has an
c) exclude attributes whose name is foo
If we can provide this alternative description of this XPath transform
as a hint, then an implementation would not need to run a full fledged
XPath engine, but just use some simple logic.
Enveloped Signature transforms is pretty streamable.
C14N transform can be streamed, if we don't have to worry about
namespaces and xml: attributes in missing ancestors - maybe there could
be a hint about them.
Thomas Roessler wrote:
On 2008-07-23 09:11:29 -0400, Sean Mullan wrote:
It seems like it is definitely worth exploring. So, as I understand,
would trigger the implementation into expecting a streaming
node-set output from the URI dereferencing.
Yep, that's the basic idea.
I would need a little more time to think about this, but I think the JSR 105
API should be able to be extended to accomodate a model like this.
Thomas Roessler wrote:
Some quick notes on some ideas that came up in the last hour or so
of the face-to-face, on how to use ds:Transforms as an extension
- We could define an "assertion transform" that isn't really a
transform, but permits an implementation to make certain
assumptions -- either about the structure of the data, or about
the structure of further transforms within the chain.
- Assuming that we define an extended transform model (which doesn't
use node-sets, but operates on some other representation of
subsets of the infoset), we could define a special-purpose
transform that switches implementations into this model without
breaking the compatibility story.
More specifically, implementations could be entitled to lazily
dereference the URI parameter in a ds:Reference, and not even
generate a node-set when the transform in question is the first
- There's also the pattern of a dereferencing transform (known from