Subject: RE: [ws-rx] Revised proposal #2 for i122 - i124
“There is NO impact on SecurityPolicy since our proposal does not introduce a new STR to the WSS header.”
This is not true. To quote your own proposal:
“One OPTIONAL means of achieving this objective is to include a security token using an additional wsse:SecurityTokenReference element from WS-Security in the SOAP security header of the message containing the CreateSequence element.”
The presence of that additional STR is also present in your message examples.
So looking at this more carefully I now feel that your proposal is particularly unsuited for use with current WSS implementations. The use of an STR in root of the WSS header is unexpected per what is described in WSS, see Appendix D of WSS 1.1 in particular. So I find your proposal to add this STR to the WSS header to be something that most WSS processors today would find unexpected and therefore the message would not be processed. I now see this as one of the most serious flaws in your proposal.
Regarding your claim that there is no impact on SecurityPolicy, that is also incorrect. There is NO SecurityPolicy binding that describes the presence of a STR in the root of the WSS header. Therefore you could not today describe what you are proposing using SP.
the intension of our proposal was never to ADD anything in terms of new security features etc. to the previous proposal, but to propose a better architecture based on existing, standardized mechanisms.
Looking at the history of the discussion in this TC, the use of the STR in the body has always been the main reason for the issues around security in RM. So it is actually the core of our proposal to describe a solution where the STR can remain in the security header by utilizing the @Usage attribute of the STR which is described in the WSS 1.0 / 1.1 OASIS Standard.
Our proposal perfectly supports WS-SecureConversation/Security Context Tokens (as yours does), since we both suggest to use a token-type independent STR as a means to associate the sequence with (any possible) token in the WSS header. Section 8 you are referring to in the current WS-SecureConversation draft actually describes ONE possible way to implement this association. As our proposal demonstrates, there are also other ways to solve this, again, based on a generic mechanisms specified in a widely adopted OASIS standard. As a voting member in the WS-SX TC, I agree that the current WS-SecureConversation Editor Draft is well on its way to become an OASIS Standard presumably in 2007, but as the discussion in WS-SX stands now, it is possible that section 8 you referred to in the current Editor Draft will change and be improved till then (see
Please see more detailed <MR>comments</MR> inline.
>From: Marc Goodner [mailto:firstname.lastname@example.org]
>Sent: Dienstag, 11. Juli 2006 18:55
>To: Prateek Mishra
>Cc: email@example.com; Gilbert Pilz; Patil, Sanjay
>Subject: RE: [ws-rx] Revised proposal #2 for i122 - i124
>I do not agree with this direction. Your proposal does not add anything
>that was not already in the previous proposal we made to the TC. All it
>does is move the STR from the body to the header. I don't understand
>this pursuit to purge RM of primitives from WSS (primitives intended
>for such reuse) when no exception is taken to the extensive reuse of
>primitives from WS-Addressing.
>This proposal is also inconsistent with the techniques to associate a
>specific token with a message described in WS-SecureConversation. You
>suggested that referencing such a technique from WS-SecureConversation
>rather than defining it from scratch would be preferable:
>"It would be much better if this text were to make reference to Section
>8 of WS-SC which describes this technique versus inventing it from
>Now you highlight as a virtue that RM should do exactly the opposite
>and define primitive security patterns that other specifications should
>I also do not believe that this proposal is consistent with
>SecurityPolicy, see text on point 4 below.
>More inline below.
>From: Prateek Mishra [mailto:firstname.lastname@example.org]
>Sent: Monday, July 10, 2006 12:27 PM
>To: Marc Goodner
>Cc: email@example.com; Gilbert Pilz; Patil, Sanjay
>Subject: Re: [ws-rx] Revised proposal #2 for i122 - i124
>Attached to this message you will find an alternative solution proposal
>that meets the requirements for i122-i124. The proposal is co-authored
>by SAP and Oracle. The proposal is expressed as a diff over your
>We believe that our proposal has certain advantages over the original
>proposal. These include:
>(1) Supports a more flexible interaction model (architecture) between
>RM and the Security layer; RM layer does not have to process or
>communicate security artefacts such as STRs. All required STRs are
>found within the SOAP message security header.
>MG: Yes but now the security layer has to communicate those artifacts
>to the RM layer at the RM layer's request, I fail to see the
>improvement. I am not convinced that what you propose is more flexible,
>it seems to enforce a rigid implementation strategy on how the security
>contract must be shared between the RM and WSS layer that is not
>described in your proposal (or WSS). That is in contrast to a well
>understood mechanism for just that purpose.
Our proposal does not require the security layer to communicate the STR to the RM layer since it is not included in the CS message any more (as opposed to your proposal). It actually avoids this tight coupling between the layers by clearly separating the elements of each protocol.
Now the RM layer is not required to have any understanding of the STR any more, and there is no need to communicate any security artifacts up the stack from the security processor to the RM layer. The RM processor is now able to manage the mapping between the sequence and the token based on an abstract handle (an unique id or number) or (based on architectural preferences and the flexibility our proposal provides) the security processor does that for RM.
>Why is it such a concern to reference WSS elements (esp. ones meant for
>reuse) as opposed to reusing WS-A primitives which we do throughout the
>What you are proposing has also not been validated by implementation
>experience. The approach that we propose has been in a slightly lesser
>form in the contributed specs. For anyone who plans to support the
>contributed specs your approach therefore represents a complication in
>that it requires two implementation approaches rather than one.
I disagree with the fact that any private, vendor-centric interoperability events are a valid argument to assume that the majority of the implementations have already adopted your proposed approach. Many vendors will wait at least for a first CS status of the SX specs, and speaking for the companies behind our proposal, one should not assume that our design is less unproven than yours.
>(2) Is based entirely on the OASIS WSS standard.
>MG: I don't see that as an advantage if it does not compose with other
>specifications such as SecurityPolicy, see below. I think ignoring the
>specs in the SX TC is a mistake.
The fact that our proposal formally only relies on the WSS 1.0/1.1 OASIS Standard does not mean that it will not compose with WS-SecureConversation. The STR works perfectly well with WS-SecureConversation and the Security Context Tokens. Regading SecurityPolicy, please see my comment below.
>(3) Provides a standard pattern which may be re-used for other
>application protocols as it is based upon profiling the STR usage
>MG: I do not believe, and you have asserted as well, that RM should not
>be defining security patterns for re-use by other applications. The
>pattern in our original proposal was described in
>You had previously asked for a reference in the proposal to the
>techniques as described there (as noted above). Now you are asserting
>that the RM TC should attack a general reusable security pattern for
>other applications rather than reusing a common technique described in
>a security specification.
To clarify this: Our proposal describes the RM-specific application of a reusable security pattern. The description of the generic pattern will be subject to the discussion around issue 77 in WS-SX (http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/20060
>(4) Has no additional impact on SecurityPolicy beyond that found in the
>MG: I disagree. Your proposal introduces a new STR in the WSS header.
>That needs to be described in the SP assertion. Please illustrate how
>you would do so, I do not believe there is an existing assertion that
>covers this unexpected use. If such an assertion existed in SP, use of
>the technique as you have described it would impact the SP layer in
>that it would then need to be reflected. Therefore there would be two
>assertions, across RM and SP, that would be emitted that are tied
>together one not making sense without the other. With our original
>proposal the SequenceSTR assertion only indicates the presence of an
>STR that will refer to the token to secure the message, nothing more.
>It would not affect what the contents of the SP assertion would be. SP
>completely defines the token to be referenced.
There is NO impact on SecurityPolicy since our proposal does not introduce a new STR to the WSS header. It only introduces a new URI value for the STR @Usage attribute to unambiguously identify the STR used to protect the RM Sequence. If you carefully read the example message and the explanation given in our proposal you'll notice that there is NO additional STR in the WSS header. Instead, the *existing* STR that is already part of the XML Signature for the RM Sequence in the WSS Header uses this URI value to identify the STR for the processor.
The WSS header actually looks (except for the @Usage attribute in one
STR) identical to your proposal. The most important difference is that our proposal does no require to duplicate the STR (which is already included in the WSS header) to the body of the message with all the advantages described in Prateek's summary.
>> This update is easy to understand but includes some important tweeks
>> that have been discussed on the list. Redlines are from the last
>> revision of this proposal posted on June 21^st .
>> First the observation Sanjay made that the header does not make any
>> sense as mU=false has been addressed, the header now must be mU=true.
>> I also added a reference to the SC section (I used the contributed
>> version rather than the SX TC editor draft) that describes
>the use of
>> an STR in a message body to address Prateek's concern that the RX TC
>> not invent new mechanisms. The concern Gil mentioned that
>> be advice to favor a message independent reference over a local
>> reference has also been added.
>> Other than that I corrected a few 2119 terms that were not in caps.
>> (Sorry if this is a dupe, I forgot the subject line and the OASIS
>> mailer said it bounced)