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:07:17 UTC