Re: Formal objection to the binding of [reference properties] in SOAP

On Mon, 2005-05-16 at 12:16 -0700, Anish Karmarkar wrote:
> 1) Safety and Security
> 
> The sender of a SOAP message is typically responsible for including SOAP 
> Header
> blocks and expected to understand the implications of such inclusion. 
> The sender
> also decides the values of the mustUnderstand attribute, the actor/role
> attribute, the relay attribute, and the reinsert attribute for those SOAP
> headers and accept the consequences of these choices. SOAP headers have
> well-defined semantics and perhaps contractual obligations associated 
> with them.
> 
> Contrary to this understanding, the SOAP binding of [reference parameters]
> REQUIRES that each of the EIIs be bound as a SOAP Header blocks and treats
> these Headers blocks as opaque.

The SOAP binding specification does not say anything about requiring the
parameters to be opaque. The Core spec does say "to be opaque to
consuming applications.". I would therefore assume that it is at least
ok for the SOAP processing engine to look into the reference parameters.
Jonathan even pointed out some reasons to do so [1].

This security concern suggests treating them carefully and Addressing
APIs need to provide abilities to:
- disallow or allow the use of reference parameters altogether
- allow or disallow the use of parameters for an explicit list of
namespaces

APIs should also have their default behavior set to disallow the use of
reference parameters altogether.

Philippe

[1] http://www.w3.org/2002/ws/addr/lc-issues/#lc37