Issue 446 - STR Transform

["Martin Gudgin" <mgudgin@microsoft.com>]

I took an action to look into Issue 446 - Need clarification on STR
transform. The commentator asks the following questions, I have provided
proposed answers. I'd like the rest of the TC to look at these answers
and comment on whether they agree with them or not.

If the TC agrees with my answers, then I don't think we need do anything
beyond responding to the commentator with the answers. That is, I
believe the spec is unambiguous as written.

If the TC doesn't agree with my answers, then it's a whole different
story ;-)

Cheers

Gudge



Q1. 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?


A1. The expected result will depend on whether Inclusive or Exclusive
C14N is being used. If Inclusive C14N is being used then all the
namespace declarations which are in-scope for the security token element
(Ri' in the algorithm defined in section 8.2 of the Core) will be
present on that element. If Exclusive C14N is being used then only those
namespace declaration that are visibly utilised and those listed in
ec:InclusiveNamespaces/@PrefixList will be present on the element.
Assuming Exclusive C14N and an empty/missing
ec:InclusiveNamespaces/@PrefixList then I would expect the following
namespace declarations; xmlns:wsse, xmlns:wsu and xmlns ( per note in
Section 8,2 )




Q2. 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?


A2. No, see A1.




Q3. 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?


A3. Assuming Exclusive C14N and an empty/missing
ec:InclusiveNamespaces/@PrefixList I would expect the three namespace
declarations emitted bu WSS4J/Systinet.




Q4. 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.


A4. I think in this case then a namespace declaration for the
appropriate prefix will ALWAYS be present on the resulting BST element.
If Inclusive C14N is being used then it will either be copied from an
ancestor or added because there is no such declaration in scope. If
Exclusive C14N is being used then it will be present becase it is
visibly utilised.