Is Kavi broken?

<interruption from="our regularly
scheduled programming">

Is Kavi broken?  I got this response
from Martin but I don't remember ever seeing Tony's original note that
appears to have been sent (cc'd) to the wsrx mailing list.  I also
don't see Tony's reply in the mail archives.  Anyone know what's going
on? 

</interruption>

-Doug

"Raepple, Martin"
<> 

07/13/2006 07:27 AM

To

Anthony Nadalin/Austin/IBM@IBMUS

cc

<>

Subject

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

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

"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]