Since the execution of proxylets is triggered (or controlled) by rule
modules on the OPES box, we can support different kinds of binding between a
rule module and a proxylet, for examples --
* the virus scanning company can dictate that only authroized rule modules
get to run the latest virus scanning utility -- so it would provide some
kind of authorization code to the authorized paying parties, and these
parties have to pass the code back to the proxylet to verify before it
actually runs the scanning.
* or the virus scanning company can say that any party can run its older
version utility without paying -- thus the arbitrary (free) binding of this
proxylet and rule module.
Speaking of version, we think it is important to have a good versioning and
naming scheme for proxylet so that multiple versions of the same proxylets
can be supported in OPES box, so that the rule module can say exactly what
version of the proxylet it wants to run (like in previous 2 examples), or
simply saying "the LATEST".
Lily
-----Original Message-----
From: Hilarie Orman [mailto:HORMAN(_at_)novell(_dot_)com]
Sent: Thursday, February 01, 2001 1:46 PM
To: ietf-openproxy(_at_)imc(_dot_)org; rob(_dot_)erickson(_at_)intel(_dot_)com
Subject: Re: OPES Ownership
Perhaps we need to define explicit roles and trust
levels. Some proxylets will originate locally and
be fully trusted, others will be from partners with
mutual interests, others will be transient and subject
to low priority/low privilege.
For example, an enterprise might have a contract with
a virus scanning company; the virus company can install
any proxylets on an OPES machine local to the enterprise.
It can install its own policy, as long as it is more restrictive
than some base (like, incoming SMTP). Because the
OPES virus-scanning machine is an appliance, it can
have its own policy, saying that it accepts proxylets only
from a set of trusted virus-scanning companies.
Hilarie