RE: Using attributes to mark RefProp's and RefParam's

Dims,

If you want to know how many "gold" members, then clearly you have some 
knowledge that there
is a specific header with "gold" semantics and you simply scan the message 
for that particular header.
Why need it be identified as being a ref prop/param?

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> 
11/24/2004 09:15 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
<public-ws-addressing@w3.org>
Subject
RE: Using attributes to mark RefProp's and RefParam's






That was just an example off the top of my head. How about collecting
management information of all the refp's flowing in the system for
analysis? (How many "gold" members accessed which service and how many
times). In this scenario, we should not have to type in all the qnames
of all possible refp's in advance.

-- dims 

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Wednesday, November 24, 2004 9:06 PM
To: Srinivas, Davanum M
Cc: public-ws-addressing@w3.org
Subject: RE: Using attributes to mark RefProp's and RefParam's

Dims,

Can you give me an example of a SOAP header that you would not sign? The
security considerations section recommends signing all relevant headers.


Keep in mind that any header not signed is subject to tampering. Any
message that travels through an intermediary is subject to header
insertion (and deletion) attacks. 
Hence, a service that receives
messages should be highly suspect of any headers, regardless of type,
that are not signed. It may even implement a policy that precludes
processing of any header that is not signed by a trusted source (e.g.
the sender (which has presumably been authenticated and authorized)
and/or a trusted intermediary).

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> Sent by:
public-ws-addressing-request@w3.org
11/24/2004 07:52 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
<public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
Subject
RE: Using attributes to mark RefProp's and RefParam's







Ok. Then here's one scenario. I'd like my security proxy/intermediary to
check if all ReferenceParameters are signed and throw faults for the
rest and I don't want to keep adding new Qnames for every service that
gets added to the system.

-- dims

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Wednesday, November 24, 2004 6:45 PM
To: Srinivas, Davanum M
Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
Subject: RE: Using attributes to mark RefProp's and RefParam's

Technically viable? Yes.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> wrote on 11/24/2004
06:25:39 PM:

> So technically this is a viable solution ("we don't lose the ability 
> to leverage the SOAP processing model") right? If yes, I will write up

> some scenario for using it (intermediary/management/proxy type of
> scenario)
> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Christopher 
> B Ferris
> Sent: Wednesday, November 24, 2004 5:54 PM
> To: Srinivas, Davanum M
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: RE: Using attributes to mark RefProp's and RefParam's
> 
> 
> I'm still unclear as to why you think it necessary. If an endpoint 
> publishes an EPR with ref props and/or params, one assumes that it is 
> doing so full in the knowledge as to what it intends to do with these 
> as SOAP headers.
> The one thing that distinguishes them in the context of an EPR is that

> ref props are used in determinging EPR equivalence (e.g. that the two 
> equivalent EPRs have the same metadata (WSDL, schema, policy, etc.) 
> The intent of defining EPR equivalence is specifically so that the 
> sending node can know which policies it can expect will be applied (or

> which to apply).
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> public-ws-addressing-request@w3.org wrote on 11/24/2004 05:21:17 PM:
> 
> > Is this a hot potato? :) no replies so far :)
> > 
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > Srinivas, Davanum M
> > Sent: Wednesday, November 24, 2004 12:56 PM
> > To: public-ws-addressing@w3.org
> > Subject: Using attributes to mark RefProp's and RefParam's
> 
> > Team,
> > Me and Igor were chatting about how to mark RefProp's and RefParam's

> > on
> the way back AND still not
> > "lose the ability to leverage the SOAP processing model", here's the
> outcome?..Comments?
> > Suppose we have an EPR which says this: 
> > <wsa:EndpointReference>
> >    <wsa:Address>
> >         http://www.example.com/services/someService
> >    </wsa:Address>
> >    <wsa:ReferenceProperties>
> >         <tns:resourceID>DataChunk42</tns:resourceID>
> >    </wsa:ReferenceProperties>
> >    <wsa:ReferenceParameters>
> >         <tns:expires>32000</tns:expires>
> >    </wsa:ReferenceParameters>
> > </wsa:EndpointReference>
> > Can we have it come back as this? 
> > <SOAP-ENV:Envelope>
> >      <SOAP-ENV:Header>
> >          <wsa:MessageID>msgid:1234567902282223</wsa:MessageID>
> >
<wsa:To>http://www.example.com/services/someService</wsa:To>
> >          <wsa:Action>http://www.example.com/someAction</wsa:Action>
> > 
> > <wsa:From>http://www.example.com/clients/someClient</wsa:From>
> > 
> <wsa:ReplyTo><wsa:Address>http://www.example.com/clients/someOtherClie
> nt
> </wsa:
> > Address></wsa:ReplyTo>
> > 
> <wsa:FaultTo><wsa:Address>http://www.example.com/clients/yetAnotherCli
> en
> t</wsa:
> > Address></wsa:FaultTo>
> >          <tns:resourceID
> wsa:type="property">DataChunk42</tns:resourceID>
> >          <tns:expires wsa:type="parameter">32000</tns:expires>
> >      </SOAP-ENV:Header>
> >      <SOAP-ENV:Body>
> >         ...
> >      </SOAP-ENV:Body>
> > </SOAP-ENV:Envelope>
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> 
> 
>

Received on Thursday, 25 November 2004 02:43:29 UTC