OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]