ietf-openproxy
[Top] [All Lists]

Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt

2002-06-03 07:40:01

Haim,

Now I don't think the issue should be whether they are close by or not, but since there could be a situation that performance both on a specific message, and the OPES engine, is important, then the question is if I can propose to add an OPTION for the OPES engine to specify in the callout protocol (whatever it will be) a list of the trusted servers and their order, and insert a security signature on the list so that the chain of trust can be achieved, and billing too. and add mechanism so that each server on the chain must notify the OPES engine on his activity and status in a secured way,

The current draft already requires the callout protocol to provide the capability of transporting meta data, see Section 3.11:

  "The OPES callout protocol MUST provide a mechanism for the
   endpoints of a particular callout transaction to include in
   callout requests and responses meta data and instructions for
   the OPES data processor or callout server."

I would assume that this could include the kind of information you're talking about.

Nevertheless, one might wonder whether the benefits that could be expected from chaining callout servers outweight the increased complexity, in particular with respect to trust relationships, privacy, security, etc. Therefore, I'd be little bit hesitant to put more specific requirements for callout server chaining on the calloout protocol.

We first need to get a clear understanding about the security/privacy/etc. implications of callout server chaining, and then decide whether to support/allow it or not. The WG document on "endpoint authorization and enforcement requirements" would probably be an appropriate place to do that - would you be willing to take a crack contribute to that document?

-Markus


<Prev in Thread] Current Thread [Next in Thread>