Title: Nachricht
|
Pete,
I see
what you mean.
The
circumvent2650 copies over the namespaces into the DOM
model.
This seems to be necessary for Signature, see
This
IMHO it is the correct behaviour to populate even "empty" BST with
the
namespace nodes.
As far
as I can understand for the exclusive c14n it is
necessary to have all nodes, also namespace nodes,
available so that
exclusive c14n can work correctly - this oppionion
maybe completely wrong :-).
Regards,
Werner
-----Ursprüngliche Nachricht-----
Von:
Pete Hendry [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag,
22. September 2005 14:31
An: Dittmann, Werner
Cc:
[EMAIL PROTECTED]; [email protected]
Betreff: Re: AW: AW: AW:
STR-Transform question
I
am not arguing about the spec - we are in agreement there. What I am trying to
explain is that WSS4J is not copying the BST it received but a modified
version of it that was modified by the EnvelopeIdResolver calling
XMLUtils.circumventBug2650(doc). In my original tests the BST I sent had no
namespaces declared on it but because of the EnvelopeIdResolver all namespace
declarations of the parents of the BST were copied to it before the
STRTransform ran. This means that xmlns:wsse and xmlns:wsu were artificially
added. If it were sticking to the spec as written above the STRTransform would
simply copy the BST node to a new document as the root, but it would be the
BST as it was in the original message not after the EnvelopeIdResolver messes
around with it.
If, as per the errata, C14N is only to be applied to
the output of the STRTransform and not the input then I think WSS4J is adding
namespace declarations that should not be there on the BST (it is not only
copying it as above but instead it is modifying it then copying it). By chance
the current behaviour of WSS4J is exactly as if the STR had been replaced by
the BST in the original document and then C14N applied as this too pulls the
namespace declarations onto the BST. Whether that is correct or not is the
question.
To go back to my example, if the BST arrives
as
<wsse:BinarySecurityToken
EncodingType="...#Base64Binary"
ValueType="...#X509v3"
wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken>
the
is that not what should be C14N'd on the output (assuming only output C14N)?
This would result in
<wsse:BinarySecurityToken xmlns=""
EncodingType="...#Base64Binary"
ValueType="...#X509v3"
wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken>
Instead
what WSS4J is C14Ning is
<wsse:BinarySecurityToken
xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."
xmlns:...
EncodingType="...#Base64Binary"
ValueType="...#X509v3"
wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken>
with
the result being
<wsse:BinarySecurityToken xmlns=""
xmlns:wsse="..." xmlns:wsu="..."
EncodingType="...#Base64Binary"
ValueType="...#X509v3"
wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken>
which
is obviously different than if the original node had just been copied to the
root of a document and
C14N'd.
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]
|
