Subject: RE: Comparison of ICAP and SOAP

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 10 Jul 2001 11:04:46 -0600

If your intent is to let your teenager drive the car to the store during
daylight hours, then you've got provide a way to undo the lock.  And,
in fact, you never set the lock in the first place, you just left the
car in the driveway and need to put a note on it saying who could
drive it, where and when.

There's no trust model today for HTTP content mods; OPES will take
a big step forward in defining the model and mapping it to an
actual implementation.

Hilarie

>>> Bernard Aboba <[email-masked]> 07/10/01 12:42AM >>>

> Agree on the lack of authentication and authorization issues, these are 2 
> items OPES is proposing to address. Several of us have long believed that
> with an OPES framework, multiple existing remote procedure call
> protocols including iCAP and SOAP can be added to an authenticated and
> authorized intermediate proxy model.  By applying AAA in the form of an
> Admin Server, where authorization is classically a policy model with PRC
> modules and the like and authentication is capable of  using protocols
> such as SSL, we have the opportunity to disarm the bomb.

The missing feature is security between endpoints. You cannot get there by
adding AAA, admin servers, and yet more proxies. That is like trying to
prevent your car from being stolen by loading it up with several tons of
steel. Why not just lock the door? Object based security techniques ought
to do the job.

---

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 10 Jul 2001 11:12:56 -0600

The 'explicitly addressed' was added to explicitly address your concerns
that the IP addressing model might be violated.  Now you appear to
be getting at application level addressing or 'targeting' (what do mean
by 'arbitrary content'?).  The security model can encompass delegation
within the message to any degree of specificity, but it seems to me
that classes of delegation are the most useful principals - 'proxy',
'surrogate', 'edge proxy'.

For most publishers, these delegations, if required, likely will be added 
by reverse proxies that modify content based on pattern matching.  

Hilarie

>>> Mark Nottingham <[email-masked]> 07/10/01 10:59AM >>>

On Tue, Jul 10, 2001 at 09:39:17AM -0700, Michael W. Condry wrote:
> At 09:09 AM 7/10/2001 -0700, Mark Nottingham wrote:
> 
> 
> >SOAP intermediaries must be explicitly targetted by the message
> >(using the 'actor' attribute). In this respect, they are completely
> >unlike the OPES model.
> 
> The charter says the intermediaries are explicitly addressed. I am
> a bit confused by your comment.

Does the charter state that they will be targetted by an in-message
mechanism (e.g., HTTP response header, arbitrary message content,
etc.)?

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Jul 2001 11:12:27 -0700

On Tue, Jul 10, 2001 at 11:12:56AM -0600, Hilarie Orman wrote:
> The 'explicitly addressed' was added to explicitly address your
> concerns that the IP addressing model might be violated.

parsing... parsing...

I don't *think* I've raised any such concerns... my primary concern
has been the violation of the implied trust model on the Web, not
IP's addressing model.

> Now you appear to be getting at application level addressing or
> 'targeting' (what do mean by 'arbitrary content'?).

The phrase 'arbitary message content' was attempting to communicate
the idea that some part of a message passing through an intermediary
nominiates that message for modification, etc., rather than some
out-of-band ruleset, etc.

> The security model can encompass delegation within the message to
> any degree of specificity, but it seems to me that classes of
> delegation are the most useful principals - 'proxy', 'surrogate',
> 'edge proxy'.

In the infamous words of Pauline Hanson, "Please explain?"

> For most publishers, these delegations, if required, likely will be
> added by reverse proxies that modify content based on pattern
> matching.

This statement seems to make a number of assumptions about the
publication processes used, the nature of the content, the
publisher's relationship with the 'reverse proxies' (n.b. - WREC
discouraged this term in favour of surrogates), and the nature of the
services which will be applied.

---

From: "Carr, Wayne" <[email-masked]>
Date: Tue, 10 Jul 2001 12:55:53 -0700

> As I noted, other devices may choose to fiddle with SOAP messages (as
> with any other payload); however, they're not interposed by SOAP.
> This 'failing' is perhaps why one of the first SOAP Modules submitted
> was for XML digital signatures [2], and it's more than likely that it
> will be joined by XML Encryption ASAP.

W3C's Digital Signature Rec wasn't ready yet when SOAP was published as a
W3C Note.  Digital Signature is almost to Rec now.  Encryption should follow
fairly soon.  I think this is a matter of layering, not a failure for one
spec to include everything.

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 10:34 AM
> To: Carr, Wayne
> Cc: Brian E Carpenter; Keith Moore; Tomlinson, Gary; Randy Bush; Lloyd
> Wood; John Martin; [email-masked]; [email-masked]
> Subject: Re: Comparison of ICAP and SOAP
> 
> 
> 
> Wayne,
> 
> On Tue, Jul 10, 2001 at 10:13:21AM -0700, Carr, Wayne wrote:
> > SOAP intermediaries don't have to be explicitly targetted. 
> > Anything along the way could read and act on a soap message.  If
> > you do use the soap actor attribute, how you use it is very
> > flexible.  You can ask the next node to act on it.  You can use a
> > uri that indicates a specific node or you can use a URI that
> > indicates some action you want and you don't care who does it.
> 
> What you describe isn't a SOAP intermediary by the WG's definition -
> see [1]. Of course the actor which nominiates the intermediary
> doesn't have to be tied to the network identity of that node; my
> point was that there must be an explicit targetting of the block for
> a SOAP intermediary to be able to process it.
> 
> As I noted, other devices may choose to fiddle with SOAP messages (as
> with any other payload); however, they're not interposed by SOAP.
> This 'failing' is perhaps why one of the first SOAP Modules submitted
> was for XML digital signatures [2], and it's more than likely that it
> will be joined by XML Encryption ASAP.
> 
> Cheers,
> 
> [1]  http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478382082
> [2]  http://www.w3.org/TR/SOAP-dsig/
> 
> 
> --

---

From: "Glenn Waters" <[email-masked]>
Date: Wed, 11 Jul 2001 10:04:01 -0400

I didn't realize there were any cynics that were on this list.

/gww

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 23:37
> To: Mark Nottingham
> Cc: [email-masked]

[...] 

> 
> The cynics and realists among us read this as:
> 

[...]

> /Valdis