Trust Management for the World Wide Web

3.4REFEREE Primitive Data Types

REFEREE has three primitive data types. They are explained in this section.

3.4.1Tri-Value

Tri-values are three-valued logic operands. There are three possible values:

• 
  true
  
• 
  false
  
• 
  unknown
  

Notions of true and false are familiar from Boolean logic. The additional unknown value reflects the fact that some trust decisions are neither true nor false. For example, when asking about authorization of a particular action, such as "should the following purchase order be approved?", there are typically three possible outcomes:

• 
  true, meaning "yes, the action may be taken because sufficient credentials exist for the action to be approved."
  
• 
  false, meaning "no, the action may not be taken because sufficient credentials exist to deny the action."
  
• 
  unknown, meaning "REFEREE was unable to find sufficient credentials either to approve or to deny the requested action."
  

In the third case, the unknown value returned by REFEREE forces the host application to decide what action (if any) should be taken. If the requested action is a purchase order approval, the host application can inform relevant parties for further considerations instead of granting or denying the order.

3.4.2Statement and Statement-List

Statements are information acquired during the execution of modules. They are the common information interchange container among different modules. All statements are two-element s-expressions. The first element conveys the context of the statement and the second element provides the content of the statement. For example, if a delegation REFEREE module wants to make a statement that "Bob is not trustworthy", it can be expressed in the following statement:

( ( "delegation-program" ) ( "Bob" ( trustworthiness 0 ) ) )

If the content of a statement expresses an authorization, the context indicates the source of authority. The host application or other REFEREE modules can make more intelligent trust decisions based on not only "what does the statement say" but also "who says it". The use of statements facilitates a dynamic REFEREE execution environment; REFEREE modules can delegate trust evaluations to other modules in REFEREE and know who make the statements, just as applications can delegate trust to third parties on the network and know who make the assertions.

A statement list is an ordered list of statements. It generally acts as a transcript of statements that a REFEREE module makes.

3.4.3Module Databases

A Module database binds action names to REFEREE modules, making it possible to call a module by an action name, as is common in almost all programming languages. A module database consists of entries. Each entry is a triplet, identifier, code-fragment, and language name. Identifier is a string that uniquely identifies the entry in its local name space. Code-fragment is the actual policy statements or interpreter codes. Language name is a string to identify the language the code-fragment is written in and how to interpreter it. An example of a module database is as follows:

identifier	code-fragment	language name
download-applets		http://www.javasoft.com/jdk1.1/
view-URL		http://www.w3.org/PICS/Profiles092/
http://www.w3.org/PICS/Profiles092/		http://www.javasoft.com/jdk1.1/

Table 1 A Sample Module Database

To get a policy and interpreter pair from the database, the caller supplies an action name and a list of language names supported by REFEREE. The module database first finds the module policy by matching the action name with the entry identifier. If the match fails, the database returns an error message. If it succeeds, it checks whether the language name is in the list of language names supported by REFEREE itself. If it is, the entry is returned as the policy with no interpreter necessary. If it isn't, the database iteratively searches for lower-level interpreters that can interpret the language, until the lowest-level interpreter is written in a language interpretable by REFEREE itself. Then the policy and a list of interpreters are returned.

For example in Table 1, if the requested action name is "view-URL", then the policy is the code-fragment identified by "view-URL". The associated interpreter is the code-fragment identified by "http://www.w3.org/pub/WWW/PICS/Profiles092", assuming REFEREE supports Java JDK1.1. If the requested action name is "download-applets", then the policy is the code-fragment identified by "download-applets". There is no associated interpreter, since the code-fragment is written in Java JDK1.1.

A module database can selectively install or uninstall bindings to control the availability of the modules, by adding and removing bindings in the database. There is no security mechanism in the module database itself to determine which modules can install, uninstall, or query the database. Rather the module database is passed around as an object, and a caller module can exercise access control by removing certain module database bindings before passing it to a callee module.

The use of module databases in REFEREE facilitates a constrainable execution environment to the granularity of each individual REFEREE module invocation. If a caller does not trust a callee module entirely, a caller module can remove bindings of certain dangerous actions from a callee's module database, such as network access, filesystem access, and user interface access. The callee is therefore unable to perform these dangerous actions in the lifetime of its execution.