Trust Management for the World Wide Web

5REFEREE Reference Implementation

To verify the REFEREE design as described in the thesis, I produced a working REFEREE reference implementation as part of my thesis. I chose Java as my REFEREE underlying execution environment. The implementation work included the core REFEREE primitive data types, REFEREE API, PicsRULZ and Profiles-0.92 interpreters, and a user interface for demonstration purpose. REFEREE was ported to Jigsaw proxy as its host application.

The implementation work turned out to be a simple task. It was a two-month effort with 30 hour input per week. The ease of implementation comes from the simple and elegant design of REFEREE. REFEREE is also efficient; depending on the complexity of the policy, a REFEREE request takes between a quarter of second to half a second to evaluate, excluding the network time to fetch PICS labels. The efficiency shows that Web applications can do trust management without too much of a speed penalty.

Section one introduces the architecture of the Jigsaw proxy, the host application of my reference implementation. Section two describes how REFEREE fits in the Jigsaw proxy. Section three explains the pieces of REFEREE being implemented. Section four provides an execution trace of a sample REFEREE query. Section five discusses several insights and lessons learned from the experience of this implementation.

5.1Jigsaw Proxy: the Host Application

Jigsaw was originally designed as a Web server, whose purpose was to provide a basis for experimenting new server-side features. Recently Jigsaw introduced a Client API, which manages requests and performs filtering on behalf of a client. The Jigsaw proxy extracts pieces from both the Jigsaw Server and the Client API. The proxy front end, responsible for accepting network requests and managing them as a pool of threads, is taken from the Jigsaw Server front end. The proxy back end, responsible for redirecting requests to Web servers, is taken from the Jigsaw Client API. This section focuses on the Jigsaw proxy back end, in which REFEREE is embedded.

The Jigsaw Client API is very simple: it takes in a request (generally a URL) and returns a reply (the content of the URL). The API aims to replace the Java standard java.net.URLConnect class, with the advantages of being more robust and modular. A simplified architectural figure is shown below.

Figure 16 Jigsaw Proxy Architecture

The proxy front end listens to and receives requests from the network. It packages requests from the network and forwards them to the back end, the Client API. Internally, the Client API processes a request object through three boxes in sequence, namely ingoing filters, HTTP engine, and outgoing filters, before a reply object is generated and returned back to the proxy front end.

Ingoing filters

are a set of filters running sequentially. Each ingoing filter takes a request as input, and outputs a reply. If the reply is null, the request is handed to the next ingoing filter. If not, the Client API simply returns the reply without further processing. For example, caching can be implemented as an ingoing filter. A cache filter manages a database of cached documents, indexed by URLs. When a request flows into a cache filter, it searches the database with the requested URL. If there is a cache hit, the filter generates a reply object from the database and the Client API terminates and returns that reply object. If there is a cache miss, the filter returns a null reply and the Client API continues to the next filter.

HTTP engine

is the engine that fetches information from the network. It makes queries to the appropriate Web server through a network protocol and generates a reply object based on the information received from the network.

Outgoing filters

take both a request and a reply as input, and outputs another reply. If an outgoing filter outputs a null, the Client API continues to the next filter. If not, the Client API returns the reply object without further processing. For example, authentication can be implemented in an outgoing filter. If the input reply is "authentication required", the filter can query the host for password and run the request again, by invoking the Client API with the password.

5.2REFEREE in the Jigsaw Proxy

REFEREE is implemented as an ingoing filter in the Jigsaw proxy. When a request is received, the REFEREE filter constructs an equivalent REFEREE request object, which includes an action name and the URL of interest. The request object is then sent to the REFEREE execution environment for evaluation. If the output of the evaluation is true, the filter returns null, allowing the request to flow through without interruption. If the output is unknown or false, the filter returns a default HTML document expressing the request is blocked, along with the justifications returned by REFEREE.

One observation here is that my implementation of the Jigsaw filter has a self-regulating "policy" to respond to the outcome the REFEREE evaluation. That policy is application specific; it is neither controlled nor evaluated by REFEREE, but by the application itself. This observation reinforces the fact that REFEREE is recommendation-based; the burden to enforce the trust management decision is on the application itself. I will discuss more on this aspect in Section 5.5.

Recall from Chapter 3, there are two stages in REFEREE. The bootstrap stage corresponds to the initialization of the REFEREE filter. The query stage corresponds to the invocation of the REFEREE filter. In addition, Jigsaw provides a method (callback) to fetch information from the network. The fetch callback is implemented as the Jigsaw Client API itself, except it does not have the REFEREE filter installed.

5.3The Scope of the REFEREE Implementation

There are several pieces to the implementation:

REFEREE filter

is a Jigsaw filter that interfaces REFEREE with the Jigsaw proxy. It traps requests in a proxy and hands over to the REFEREE execution environment for evaluation.

REFEREE core module API

is a set of functions calls to initialize and invoke a REFEREE module. The same API is used by the REFEREE filter to invoke the first REFEREE module, and by REFEREE modules to invoke subordinate REFEREE modules.

REFEREE primitive data types

are a set of Java classes shared among REFEREE modules. The primitive data types include tri-values, statement-lists, and module-databases. As in any Java classes, the classes implementing these primitive data types have a set of constructors and a set of methods. For example, tri-value class has a set of constructors to create true, false, and unknown objects, and a set of methods to perform and, or, not, false-if-unknown, and true-if-unknown operations. The threshold-and in Profiles-0.92 language is a special operator implemented in the Profiles-0.92 interpreter only.

Profiles-0.92 interpreter

is a trust policy language interpreter implemented as a REFEREE module. It accepts two mandatory arguments, the URL of interests and a list of unconditionally trusted statements. It also accepts a list of optional arguments. The returned tri-value and statement-list is bound to the returned values of the last policy statement evaluation.

PicsRULZ interpreter

is a trust policy language interpreter implemented as a REFEREE module. It accepts one required input argument, the URL of interest, and no optional arguments. The returned tri-value is either a true or a false, because PicsRULZ operates on Boolean logic. The returned statement-list is null, because PicsRULZ does not return a justification with an answer. Internally, the PicsRULZ interpreter translates the PicsRULZ policy to Profiles-0.92 policy first and then invokes the Profiles-0.92 interpreter with the translated policy.

Label Loader

is a PICS trust protocol implemented as a REFEREE module. There are four required input arguments, a statement-list, a URL of interest, a rating service URL, and a list of label sources. The input statement-list contains a set of cached PICS labels. When there is a cache hit, Label Loader returns the label without fetching it from the network. The URL of interest and the rating service URL specify what PICS labels to fetch. A list of places to find labels includes embedded in a document (by the keyword "EMBEDDED"), via the HTTP header stream (by the keyword "ALONG-WITH"), or from a list of label bureaus.

The returned value is true if any label is found, unknown if all label bureaus cannot be contact, or false if label bureaus can be contacted but no label is returned. The returned statements are parsed PICS labels, which are restructured in a way that are easy for pattern matching and other operations. The exact syntax is in Appendix C.. An example is illustrated below, assuming a Profiles-0.92 policy calls Label Loader (local name "load-label") in the following line:

(invoke "load-label" STATEMENT-LIST URL

"http://www.musac.org/v1.0"

(EMBEDDED "http://www.bureau.com")

if Label Loader finds only an embedded PICS label, the returned tri-value is true, and the returned statement-list looks like the following:

(("load-label")

(("load-label" "http://www.w3.org/Overview.html" EMBEDDED)

((version "PICS-1.1")
(service "http://www.musac.org/v1.0")
(by "mailto:[e-mail]")
(original (PICS-1.1 "http://www.musac.org/v1.0"

labels by "mailto:[e-mail]"

ratings (s 1 v 0))
(ratings (s 1) (v 0)))))

As the thesis is written, the implementation of the Load Label module does not have a running PICS protocol. Instead the input of the raw PICS labels are provided by an input stream from the REFEREE filter. The implementation does parse PICS labels and turn them into REFEREE statements.

Label endorser

is a REFEREE module that handles requests for deferral of trust. The module takes three arguments, the name of the auditor, a list of label bureaus, and a statement-list to be endorsed. For each label (represented as a statement) in the statement-list, the module requests additional labels to vouch for the label author (rater) by the name auditor. This module is useful if an application does not know all the raters on the Internet, and instead trust a single auditor who endorses trustworthy raters.

The returned tri-value is true if any label in a statement-list is endorsed, unknown if the input statement-list contains no PICS label to be endorsed, and false if all labels in the statement-list fail to be endorsed. The returned statements simply adds the Label Endorser module's identifier in the statement context and the auditor's name in the statement content on top of the endorsed statement. For example, if an auditor "[e-mail]" endorses the rater "[e-mail]" from the above statement, the new statement becomes

(("endorse-label" "load-label")

("mailto:[e-mail]"

("load-label" "http://www.w3.org/Overview.html" EMBEDDED)

((version "PICS-1.1" )
(service "http://www.musac.org/v1.0")
(by "mailto:[e-mail]")
(original

(PICS-1.1 "http://www.musac.org/v1.0"

labels

by "mailto:[e-mail]"

ratings (s 1 v 0))
(ratings (s 1) (v 0)))))

As the time the thesis is written, this module is a stub; the REFEREE filter provides an input stream in which a list of trusted auditors are provided explicitly.