RE: [wss-comment] Public Comment

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Re: "This [(inclusion of wsse and wsu namespace declarations)] is understandable before the errata as the input was to be C14Nd which would pull the wsse and wsu namespace declarations onto the BST"
 
The BST is not an input to the transform (the input is the STR), so pre-errata (when the *input* was to be C14N'ed) you would *not* expect the wsse and wsu namespace declarations on the BST.
 
*After* the errata, when the *output* (which, contrary to the input, *does* include the BST) is to be C14N'ed, you would expect the output would include the wsse and wsu namespace declarations to be in C14N form.
 
So, I think that the errata text is correct as is and is consistent with your experience in interop testing.
 
&Thomas.

________________________________

From: comment-form@oasis-open.org [mailto:comment-form@oasis-open.org]
Sent: Thu 9/22/2005 9:11 PM
To: wss-comment@lists.oasis-open.org
Subject: [wss-comment] Public Comment



Comment from: peter.hendry@capeclear.com

Name: Peter Hendry

Title: Principal Engineer

Organization: Cape Clear Software

Regarding Specification: SOAP Message Security V1.1



As an implementor of the specification I am having some trouble with the description of STRTransform. I believe it is not clear what the exact behaviour is in some cases.



Assuming V1.0 Errata section 4.5 is applied - i.e. the C14N applies to the output node not the input of the STRTransform, I would like clarification of expected results under different circumstances. I do not believe the specification is clear enough about namespace handling, and after raising the issue on the wss4j list it seems I am not the only implementor with this problem.



If the input to the STRTransform is the STR



<wsse:SecurityTokenReference

    wsu:Id="id28008463">

  <wsse:Reference URI="#id3125250" ValueType="...#X509v3"/>

</wsse:SecurityTokenReference>



with no namespace declarations, and the URI referenced is



<wsse:BinarySecurityToken

    EncodingType="...#Base64Binary"

    ValueType="...#X509v3"

    wsu:Id="id3125250">xa...</wsse:BinarySecurityToken>



Then what is the expected result of the transform? No C14N is performed on the input (as per the errata). The STR is replaced with the BST - the STR being the apex the BST becomes the apex. There is no mention of adding namespace declarations to make the node valid in isolation so this would be normalized to produce



<wsse:BinarySecurityToken

    xmlns=""

    EncodingType="...#Base64Binary"

    ValueType="...#X509v3"

    wsu:Id="id3125250">xa...</wsse:BinarySecurityToken>



Is this correct? While doing interop testing against WSS4J and Systinet the result has to be



<wsse:BinarySecurityToken

    xmlns=""

    xmlns:wsse="..."

    xmlns:wsu="..."

    EncodingType="...#Base64Binary"

    ValueType="...#X509v3"

    wsu:Id="id3125250">xa...</wsse:BinarySecurityToken>



This is understandable before the errata as the input was to be C14Nd which would pull the wsse and wsu namespace declarations onto the BST, but is it correct with the errata change?



Secondly, where the STR does not point to a BST but instead contains a reference (such as X509SubjectKeyIdentifier) then a BST is to be created with the same namespace prefix as the STR. However, it does not mention whether that namespace prefix declaration should be added to the BST. If, as above, the BST becomes the apex and is C14N'd then it makes a difference as to whether there is a namespace declaration or not as to what is output.



Examples of each case would be useful where namespace declarations do not already appear on the BST on the input to show what happens during the processing.



---------------------------------------------------------------------
To unsubscribe, e-mail: wss-comment-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wss-comment-help@lists.oasis-open.org