Re: Enveloped Signature Transform, XPath Transform: function here()

Hi Gregor,

See [1] and followups [2]. There are also previous comments on this.
There are requirements whereby here() or some equivalent function
is required [3]. A proposed solution exists [4] and there was some
discussion at IETF [5] but I can't tell what the outcome was. I
suspect that this will be further discussed in the upcoming
teleconferences [6].



>Hi all!
>I am facing severe troubles with implementing the REQUIRED
>Enveloped Signature Transform, since it violates (in my
>opinion) the basic concept of transforms:
>1. A transform has one implicit parameter: An octet stream
>   form the Reference or the output of an earlier Transform.
>2. All other parameters can be specified via the XML content
>   of the Transform element.
>3. There are no other means to tell the Transforms about 
>   additional parameters.
>Now, if I have to implement the Enveloped Signature Transform,
>I cannot compute the result of the function here(), which is
>used in the XPath expression for this transform. It makes
>no difference if I implement the transform using a XPath
>engine or with other means: 
>The result of here() should be the node which 
>bears the XPath expression. But it is impossible to get this
>result into the Transform, since a Transform operates on
>Octets and not on a tree.
>Of course it is possible to write a hack, in which the Transform
>implementation has access to the tree where the XPath expression's
>parent resides, and which does not operate on a Octet input stream.
>But, it IS a hack, and does not fit in the concept of Transforms,
>which should be a generic mechanism as described above.
>I don't see any really good reason to provide the Enveloped Signature
>Transform at all, since the author should know where the Signature
>element resides in the XML document, and can cut it out by means
>of an XPath transform, which does not contain the here() function.
>At least we should consider not to make this Transform REQUIRED. 
>Finally, the same problem applies to the XPath transform itself, because
>this sinister here() function is added to the function library by
>our specification.
>Regards, Gregor
>Gregor Karlinger
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications

Received on Friday, 11 August 2000 10:11:38 UTC