I don't follow your concern here. Maybe the pseudo-code for
step 5 / slide 3 is misleading. All it says is: RM processor
asks the Security Processor to return an abstract handle for the token that is
referenced by the STR with Usage attribute set to the value ".../SequenceToken"
in the WSS Header. IMHO, this simple operation does not violate any of the
WSS processing rules and non-normative App. D in WSS is neutral wrt
@Usage.
- Martin
From: Anthony Nadalin
[mailto:]
Sent: Mittwoch, 12. Juli 2006
23:48
To: Raepple, Martin
Cc:
Subject: Re: FW: [ws-rx] Revised proposal
#2 for i122 - i124
You have seem to require changes in every WSS stack with step 5, this is
not acceptable.
Anthony Nadalin | Work 512.838.0085 | Cell
512.289.4122
'
src="gif00018.gif" width=16 border=0>"Raepple, Martin"
<>
"Raepple, Martin"
<>
07/12/2006 02:24 PM
To
<>
cc
Subject
FW: [ws-rx] Revised proposal #2 for i122 -
i124
All,
as
an informal supplement to our proposal, please find a technical
analysis of
the different processing models behind the current proposals
wrt. issues
122 - 124.
I'd also like to propose some time on the agenda of our call
this week
to discuss these slides in the context of the security
issues.
Thanks and regards,
Martin
-----Original
Message-----
From: Prateek Mishra [mailto:]
Sent: Montag, 10. Juli 2006 21:27
To: Marc Goodner
Cc:
; 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.
(2) Is
based entirely on the OASIS WSS standard.
(3) Provides a standard pattern
which may be re-used for other
application protocols as it is based upon
profiling the STR usage
attribute.
(4) Has no additional impact on
SecurityPolicy beyond that found in the
original
proposal.
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)
>
[attachment
"Processing models.ppt" deleted by Anthony Nadalin/Austin/IBM]
