RE: Composibility problems with refps

I think David meant it the other way around. By sending this header I am
not asking the recipient to send me their assets, I am giving them the
permission to take mine. Basically the headers means "I agree to give
you all my assets". And if I sign the message, I have signed this
header...

A wrapper would clearly say "anything inside this wrapper is there only
for the purpose of routing and the sender does not make any statement in
sending them other than saying that s/he has been requested to do so in
order for the message to be delivered". But this would break the benefit
of being able to create an EPR for an existing application that already
uses SOAP headers.

A less intrusive approach (than a wrapper) would be a
<wsa:CoverMyRearside/> header (which the sender could mark
MustUnderstand) with pointers to all the headers that I put in the
message only because I was requested to do so by the EPR and that I do
not intend to stand behind.

William


-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Christopher B
Ferris
Sent: Monday, November 22, 2004 4:07 PM
To: David Orchard
Cc: public-ws-addressing@w3.org
Subject: RE: Composibility problems with refps


David,

That's a pretty far fetched example:-) Why would I choose to
"understand" 
<allYourAssetsAreBelongToUs/>?

And how is the example you give an example of duplicate user headers
(whatever they are)? And what makes you say that duplicates would
necessarily be a security hole? And how does a wrapper mitigate against
any of this?

By your account, we shouldn't have a SOAP processing model at all
because some unscrupulous client could stick in a <sendMeAllYourAssets
soap:mustUnderstand='true'/> header block.

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



"David Orchard" <dorchard@bea.com>
11/22/2004 06:15 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
<public-ws-addressing@w3.org>
Subject
RE: Composibility problems with refps






I'm not worried about ref props/params interfering with WS-* use of
headers by a bad interface design.  The owner of the interface controls
both the use of WS-* specs and the use of RefPs.  They will quickly sort
out any interface conflicts.  And my guess is that Rule #1 of RefP usage
will be: Thou shalt not use WS-* QNames in RefPs.

I'm more sensitive to the issue 8 concern about ref props/params being
duplicates of user headers, particularly a security hole that allows a
hacker to put a bad RefP into the EPR, ie <SendAssetsToGrandCayman
amount="all" fromacct="chris" toacct="hacker"/>

This security problem isn't covered by signing the EPR but is covered by
a wrapper of some kind.

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Christopher B Ferris
> Sent: Monday, November 22, 2004 1:10 PM
> To: Anish Karmarkar
> Cc: Jonathan Marsh; public-ws-addressing@w3.org; public-ws-addressing-

> request@w3.org; tom@coastin.com
> Subject: Re: Composibility problems with refps
> 
> 
> Anish/Tom,
> 
> But then this means that the refps that under the current design
become
> SOAP headers, and subject to
> the SOAP processing model, would no longer be subject to the SOAP 
> processing model. I think that this would be a collossal mistake.
> 
> Frankly, I think that the idea of reference properties/params
interfering
> with other WS-* use of headers
> is a red herring. Of course, it is always possible to do something
that
> would break any protocol. At most, I could see adding a note in the 
> spec that recommended caution when including
any
> protocol elements
> as reference property/parameters as their subsequent inclusion as SOAP

> header blocks in messages addressed to the endpoint *might*, I repeat,

> *might* conflict with constraints as to cardinality of such header 
> blocks in a message, etc.
> 
> I would strongly discourage any thoughts of a wrapper element for 
> reference property/parameters.
> 
> 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
> 
> 
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com> Sent by: 
> public-ws-addressing-request@w3.org
> 11/22/2004 02:03 PM
> 
> To
> tom@coastin.com
> cc
> Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org 
> Subject
> Re: Composibility problems with refps
> 
> 
> 
> 
> 
> 
> 
> I agree that would indeed solve the problem -- either refp specific
> header(s) or the use of [to] property.
> 
> -Anish
> --
> 
> Tom Rutt wrote:
> 
> >
> > As Glen has suggested before, encapsulating the ref parms and ref
props
> > in a ws-addressing specific header element would allow arbitrary 
> > qnames for the ref props and ref parms, without confusion.
> >
> > Tom Rutt
> >
> > Anish Karmarkar wrote:
> >
> >>
> >> Yes.
> >> Or in the context of SOAP, composability with any specification
that
> >> uses SOAP header(s) as a mechanism to convey information.
> >>
> >> -Anish
> >> --
> >>
> >> Jonathan Marsh wrote:
> >>
> >>> Specifically, you're worried about the case where the reference 
> >>> properties and reference parameters are in a namespace used by the

> >>> reliability, security, etc. mechanisms, right?
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: public-ws-addressing-request@w3.org [mailto:public-ws- 
> >>>> addressing-request@w3.org] On Behalf Of Anish Karmarkar
> >>>> Sent: Monday, November 15, 2004 11:10 AM
> >>>> To: public-ws-addressing@w3.org
> >>>> Subject: Composibility problems with refps
> >>>>
> >>>>
> >>>> All,
> >>>>
> >>>> During last week's concall discussion of issue i008 I took an
action
> >>>> to
> >>>> explain the composibility problem with refps in an email. This
email
> >>>> fulfills that action.
> >>>>
> >>>> WS-Addressing [1] Submission includes [reference properties] and 
> >>>> [reference parameters] in the info models for EPR. These refps
are
> >>>> opaque to the consumer. In the SOAP binding of EPR, the refps are

> >>>> bound as individual SOAP header blocks. I.e., a consumer of a EPR

> >>>> using
> SOAP
> >>>> is required to copy the refps as individual SOAP header blocks
> without
> >>>> understanding what the blocks mean or do.
> >>>>
> >>>> Typically SOAP header blocks are part of a SOAP module and
express
> >>>> certain functionality. For example, WSS, WS-Reliability, 
> >>>> WS-ReliableMessaging, WS-C, WS-T WS-Context etc, specify header
> blocks
> >>>> that have a particular meaning that is conveyed from the sender
to
> the
> >>>> receiver. Specifications in the realm of Web services are
designed to
> >>>> be
> >>>> composible with other specs. For example, WS-Context can be
composed
> >>>> with WS-Reliability and WSS.
> >>>>
> >>>> A consuming application that dereferences an EPR that contains
refps
> >>>> may
> >>>> have some policies in place wrt to reliability, security, 
> >>>> coordination, transaction, privacy etc. Given that refps may 
> >>>> contains any XML
and
> >>>> these refps are bound as SOAP header blocks, refps can
potentially
> >>>> interfere with composibility of WS-Addressing with other WS-*
specs
> >>>> that
> >>>> the consumer may be using. The opacity of the refps prevents the 
> >>>> consumer from making any inferences about the refps in an EPR.
> >>>>
> >>>> This issue is slightly different from the security of EPRs --
which
> >>>> *may* potentially be resolved by requiring the minter of the EPR
to
> >>>> sign
> >>>> the EPR.
> >>>>
> >>>> HTH to clarify the issue.
> >>>>
> >>>> -Anish
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>> [1]
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> 
> 
>

Received on Tuesday, 23 November 2004 00:13:55 UTC