FW: [wss] Issue 446 - STR Transform

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

This didn't seem to make it to the list...

Gudge

-----Original Message-----
From: Pete Hendry [mailto:peter.hendry@capeclear.com] 
Sent: 17 October 2005 20:49
To: Martin Gudgin
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] Issue 446 - STR Transform

The reason these questions arose was because, while debugging my 
STRTransform implementation, I adventured into the WSS4J STRTransform 
implementation because I was getting a different result from it. While 
looking at their algorithm I was unclear as to the points below.

The primary issue was that WSS4J was (I believe they have since changed 
this) creating a new BST with any required prefixes defined on it and 
then C14N'ing it in isolation. This means it was not being inserted to 
replace the STR in the original docuemnt and the BST was actually being 
treated as the root of the document. This seemed odd to me but reading 
the STRTransform description in the specification it was not clear 
whether this was the intended behaviour or not. As it turned out it 
produced the expected result because the tests only used exclusive C14N 
(inclusive would have failed as the ancestor context was lost) and 
during the creation of the BST the relevant namespace (wsse) was always 
added explicitely.

This raised the 2 questions paraphrased here as

- should the BST be inserted in the document to replace the STR and then

C14N'd in this context?
- should the namespace prefix *always* be added (it may not make a 
difference after C14N but the behaviour should be clear)
   or only where the ancestor context does not contain the mapping?

I think these 2 sum up the crux of the 4 questions.

Pete

Martin Gudgin wrote:

>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.
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>