RE: [ws-rx] Revised proposal #2 for i122 - i124

["Marc Goodner" <mgoodner@microsoft.com>]

Prateek, 

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
scratch"
http://lists.oasis-open.org/archives/ws-rx/200607/msg00019.html 
Now you highlight as a virtue that RM should do exactly the opposite and
define primitive security patterns that other specifications should
copy.

I also do not believe that this proposal is consistent with
SecurityPolicy, see text on point 4 below.

More inline below.

-----Original Message-----
From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
Sent: Monday, July 10, 2006 12:27 PM
To: Marc Goodner
Cc: ws-rx@lists.oasis-open.org; Gilbert Pilz; Patil, Sanjay
Subject: Re: [ws-rx] Revised proposal #2 for i122 - i124

Marc,

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
original proposal.

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.

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
RM specification?

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. 

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

(3) Provides a standard pattern which may be re-used for other
application protocols as it is based upon profiling the STR usage
attribute.
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 WS-SecureConversation.
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.

(4) Has no additional impact on SecurityPolicy beyond that found in the
original proposal.
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.

Thanks,
prateek mishra

> 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 .
>
> http://lists.oasis-open.org/archives/ws-rx/200606/msg00164.html
>
> 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.
>
> http://lists.oasis-open.org/archives/ws-rx/200606/msg00259.html
>
> 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 there should

> be advice to favor a message independent reference over a local 
> reference has also been added.
>
> http://lists.oasis-open.org/archives/ws-rx/200607/msg00035.html
>
> 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)
>