- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 14 Mar 2005 08:17:56 -0800
- To: Rich Salz <rsalz@datapower.com>, Hugo Haas <hugo@w3.org>
- CC: public-ws-addressing@w3.org
In my view, all the security information shd be collected together and shd go in the policy sub-bucket of the metadata bucket. But there are many subtleties here depending on which direction the message is flowing etc. I suggest that the WS-Addressing WG not attempt to solve this problem. The existence of a metadata bucket(in place or by reference) is fine. The details shd be left to another WG. All the best, Ashok > -----Original Message----- > From: public-ws-addressing-request@w3.org > [mailto:public-ws-addresspendiing-request@w3.org] On Behalf Of Rich Salz > Sent: Monday, March 14, 2005 7:31 AM > To: Hugo Haas > Cc: public-ws-addressing@w3.org > Subject: Re: Proposing a wsa:Security element > > > > Couldn't such information go in the [metadata] bucket? It > seems that > > we added it for things just like that. > > Perhaps. If you see my longer note about "trust model," > you'll see that we need a way to aggregate a bunch of > security information, and make sure it ends up in a > WS-Security element. This may be different from other > security information that just needs to be used between the > client and the epr minter (which, I know, if out of scope; > out security model should support some kind of interaction > there, however). > > Yes, a wsa:Security can go into the metadata bucket. But > saying that all or any ds:Signature, > wsse:SecurityTokenReference, etc., elements get the kind of > binding I propsed for wsa:Security, is a mistake. > > /r$ > > -- > Rich Salz, Chief Security Architect > DataPower Technology > http://www.datapower.com > XS40 XML Security Gateway > http://www.datapower.com/products/xs40.html > > >
Received on Monday, 14 March 2005 16:19:13 UTC