KAoS Policy and Domain Services:Toward a Description-Logic Approach to PolicyRepresentation, Deconfliction, and Enforcement

A. Uszok, J. Bradshaw, R. Jeffers, N. Suri, P. Hayes, M. Breedy, L. Bunch, M. Johnson, S. Kulkarni, J. LottInstitute for Human and Machine Cognition (IHMC), Univ. West Florida, 40 S. Alcaniz, Pensacola, FL 32501

{auszok, jbradshaw, rjeffers, nsuri, phayes, mbreedy, lbunch, mjohnson, skulkarni, jlott}@ai.uwf.edu

Abstract

In this paper, we describe our initial implementation ofthe KAoS policy and domain services. While initiallyoriented to the dynamic and complex requirements ofsoftware agent applications, the services are also beingadapted to general-purpose grid computing and webservices environments as well. The KAoS services relyon a DAML description-logic-based ontology of thecomputational environment, application context, and thepolicies themselves that enables runtime extensibilityand adaptability of the system, as well as the ability toanalyze policies relating to entities described at differentlevels of abstraction. An online theorem-prover is usedfor policy disclosure, conflict detection, andharmonization, and for reasoning about domainstructure and concepts. In future versions, DAML will bereplaced by OWL, and description-logic will besupplemented with the possibility of rule-basedrepresentation.

Keywords: policy, agent, ontology, DAML, domains,KAoS, description logic, policy conflict resolution.

1. Introduction

The increased intelligence afforded by softwareagents is both a boon and a danger. By their ability tooperate independently without constant humansupervision, they can perform tasks that would beimpractical or impossible using traditional softwareapplications. On the other hand, this additionalautonomy, if unchecked, also has the potential ofeffecting severe damage in the case of buggy ormalicious agents. Techniques and tools must bedeveloped to assure that agents will always operatewithin the bounds of established behavioral constraintsand will be continually responsive to human control [3,7]. Moreover, the policies that regulate the behavior ofagents should be continually adjusted so as to maximize

their effectiveness in both human and computationalenvironments [6].

Under DARPA and NASA sponsorship, we havebeen developing the KAoS [4, 5, 7] policy and domainservices to increase the assurance with which agents canbe deployed in a wide variety of operational settings. Inconjunction with Nomads [18, 19] strong mobility andsafe execution features, KAoS services and tools allowfor the specification, management, conflict resolution,and enforcement of policies within the specific contextsestablished by complex organizational structures. Whileinitially oriented to the dynamic and complexrequirements of software agent applications, the servicesare also being adapted to general-purpose gridcomputing (http://www.gridforum.org) and web services(http://www.w3.org/2002/ws/) environments as well.

Following a discussion of the background andmotivation for our approach (section 2), we will providean overview of the KAoS Policy Ontologies (KPO),which represent policies, the relevant computationalenvironment, and application context declaratively usingthe DARPA Agent Markup Language (DAML) (section3). Then we present our approach to policy conflictdetection and resolution (section 4). As a next step, weshow details of the current implementation of the Policyand Domain Services in KAoS including policydistribution, disclosure, and enforcement mechanisms(section 5). Finally, we describe current applications ofKAoS and Nomads (section 6) along with its limitationsand plans for future work (section 7).

2. Background and motivation

Interest in policy-based management approaches hasgrown considerably in popularity over the last years(http://www.policy-workshop.org). The scope of ourpolicy-based agent management approach includes thetypical security concerns such as authorization,encryption, access and resource control policies, but alsogoes beyond these in significant ways. For example,KAoS pioneered the concept of agent conversation

policies [4, 5, 10]. In addition to conversation policies,we are in the process of developing representations andenforcement mechanisms for mobility policies [15],domain registration policies, and various forms ofobligation policies (see below).

There are some important differences, however,between the objectives of our approach and that of othermore typical approaches. First, the approach does notassume that we are dealing with a homogeneous, staticset of components. Our approach seeks to enable policyuniformity in domains that might be simultaneouslydistributed across multiple platforms and executionenvironments, as long as semantically equivalentmonitoring and enforcement mechanisms are available.Second, insofar as possible the framework needs tosupport dynamic runtime policy changes, and not merelystatic configurations determined in advance. Third, theframework needs to be extensible to a variety ofexecution platforms with different enforcementmechanisms—initially Java and Aroma [18, 19]—but inprinciple any platform for which policy enforcementmechanisms may be written. Fourth, the framework mustbe robust and adaptable in continuing to manage andenforce policy in the face of attack or failure of anycombination of components. Finally, we recognize theneed for easy-to-use policy-based administration toolscapable of containing domain knowledge and conceptualabstractions that let application designers focus theirattention more on high-level policy intent than onimplementation details. Such tools require sophisticatedgraphical user interfaces for monitoring, visualizing, anddynamically modifying policies at runtime.

In short, the policy management framework mustensure maximum freedom and heterogeneity of thecomponents and non-intrusiveness of the enforcementmechanisms, while respecting the bounds of human-determined constraints designed to ensure selectiveconformity of behavior.

3. KAoS policy ontologies

The representation chosen to describe the policies andtheir context largely determines the flexibility,extensibility, and amenability to analysis of a givenimplementation. KAoS services rely on a DAMLdescription-logic-based ontology of the computationalenvironment, application context, and the policiesthemselves that enables runtime extensibility andadaptability of the system, as well as the ability toanalyze policies relating to entities described at differentlevels of abstraction. The representation facilitatescareful reasoning about policy disclosure, conflictdetection, and harmonization, and about domainstructure and concepts.

3.1. Short overview of DAML

The KAoS Policy Ontologies (KPO) are expressedin DAML (http://www.daml.org). Designed to supportthe emerging “Semantic Web,” DAML is the latest in asuccession of Web markup languages [2]. HTML, thefirst Web markup language, allowed users to markupdocuments with a fixed set of formatting tags for humanuse and readability. XML allows users to add arbitrarystructures to their documents but expresses very littledirectly about what the structures mean. RDF (ResourceDescription Format) encodes meaning in sets of subject-verb-object triples, where elements of these triples mayeach be identified by a URI (typically a URL). OWL(Ontology Web Language), a W3C-approved evolutionof DAML, i s nea r ing f ina l r e l ease(http://www.w3.org/2001/sw/).

DAML extends RDF to allow users to specifyontologies composed of taxonomies of classes andproperties, as well inference rules. These ontologies canbe used by people for a variety of purposes, such asenabling more accurate or complex Web searches.Agents can also use semantic markup languages tounderstand and manipulate Web content in significantways; to discover, communicate, and cooperate withother agents and services; or, as we outline in this paper,to interact with policy-based management services andcontrol mechanisms.

3.2. Core ontologies for policy definition

The current version of KPO defines basic ontologiesfor actions, actors, groups, places, various entities relatedto actions (e.g., computing resources), and policies.There are currently 79 classes and 41 properties definedin the basic ontologies. It is expected that for a givenapplication, the ontologies will be further extended withadditional classes, individuals, and rules.

The actor ontology distinguishes between peopleand various classes of software agents or componentsthat can be the subject of policy. Most agents can onlyperform ordinary actions, however various agents thatare part of the infrastructure as well as authorized humanuser may variously be permitted or obligated to performcertain policy actions, such as policy approval andenforcement. Groups of actors or other entities may bedistinguished according to whether the set of members isdefined extensionally (i.e., through explicit enumerationin some kind of registry) or intentionally (i.e., by virtueof some common property such as a joint goal that allactors possess or a given place where various entitiesmay be currently located).

3.3. Representing policies in DAML

A policy is a statement enabling or constrainingexecution of some type of action by one or more actorsin relation to various aspects of some situation. Ourcurrent policy ontology distinguishes betweenauthorizations (i.e., constraints that permit or forbidsome action) and obligations (i.e., constraints thatrequire some action to be performed, or else serve towaive such a requirement) [8].

In DAML, a policy is represented as an instance ofthe appropriate policy type with associated values forproperties: priority, update time stamp and a site of

enforcement. The most imported property value is,however, the name of a controlled action class. Usually,a new action class is built automatically when a policy isdefined. Through various property restrictions, a givenpolicy can be variously scoped, for example, either toindividual agents, to agents of a given class, to agentsbelonging to a particular group, or to agents running in agiven physical place or computational environment (e.g.,host, VM). Additionally, action context can be preciselydescribed by restricting values of its properties. Figure 1

shows an example of the policy written in DAML statingthat the members of some domain called Arabello-HQare forbidden to communicate with the outside of this

Figure 1. Example policy in DAML

<?xml version="1.0" ?> <!DOCTYPE P1 [ <!ENTITY policy "http://ontology.coginst.uwf.edu/Policy.daml#" > <!ENTITY action "http://ontology.coginst.uwf.edu/Action.daml#" > <!ENTITY domains "http://ontology.coginst.uwf.edu/ExamplePolicy/Domains.daml#" > ]> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:daml="http://www.daml.org/2001/03/daml+oil#" xmlns:policy="http://ontology.coginst.uwf.edu/Policy.daml#" > <daml:Ontology rdf:about=""> <daml:versionInfo>$ http://ontology.coginst.uwf.edu/ExamplePolicy/P1.daml $</daml:versionInfo> <daml:imports rdf:resource="http://www.daml.org/2001/03/daml+oil" /> <daml:imports rdf:resource="http://ontology.coginst.uwf.edu/Policy.daml" /> <daml:imports rdf:resource="http://ontology.coginst.uwf.edu/Action.daml" /> <daml:imports rdf:resource=" http://ontology.coginst.uwf.edu/ExamplePolicy/Domains.daml" /> </daml:Ontology> <daml:Class rdf:ID="P1Action"> <rdfs:subClassOf rdf:resource="&action;NonEncryptedCommunicationAction" /> <rdfs:subClassOf> <daml:Restriction> <daml:onProperty rdf:resource="&action;#performedBy" /> <daml:toClass rdf:resource="&domains;MembersOfDomainArabello-HQ" /> </daml:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <daml:Restriction> <daml:onProperty rdf:resource="&action;#hasDestination" /> <daml:toClass rdf:resource="&domains;notMembersOfDomainArabello-HQ" /> </daml:Restriction> </rdfs:subClassOf> </daml:Class> <policy:NegAuthorizationPolicy rdf:ID="P1"> <policy:controls rdf:resource="#P1Action" /> <policy:hasSiteOfEnforcement rdf:resource="&policy;ActorSite" /> <policy:hasPriority>1</policy:hasPriority> <policy:hasUpdateTimeStamp>446744445544</policy:hasUpdateTimeStamp> </policy:NegAuthorizationPolicy>

domain using unencrypted communication. The syntaxof this example may seem very complex, however, theDAML policy is not meant to be written or analyzed bya human but by the computer. A graphical interfacehides the complexity of this representation from the user.

4. Policy conflict resolution

The KAoS Policy Ontologies are intended for avariety of purposes. One obvious application is duringinference relating to various forms of online or offlineanalysis. They can be used for a variety of purposes,including policy disclosure management, reasoningabout future actions based on knowledge of policies inforce, and in assisting users of policy specification toolsto understand the implications of defining new policiesgiven the current context and the set of policies alreadyin force.

In the current version of KAoS, changes or additionsto policies in force or a change in status of an actor (e.g.,a human administrator being given new permissions;software agent joining a new domain or moving to a newhost) requires logical inference to determine first of allwhich policies are in conflict and second how to resolvethese conflicts [16]. We have implemented a general-purpose algorithm for policy conflict detection andharmonization whose initial results promise a highdegree of efficiency and scalability.

Figure 2. Types of policy conflictsFigure 2 shows the three types of conflict that can

currently be handled: positive vs. negative authorization(i.e., being simultaneously permitted and forbidden fromperforming some action), positive vs. negative obligation(i.e., being both required and not required to performsome action), and positive obligation vs. negativeauthorization (i.e., being required to perform a forbiddenaction). We have developed policy deconfliction and

harmonization algorithms within KAoS to allow policyconflicts to be detected and resolved even when theactors, actions, or targets of the policies are specified atvery different levels of abstraction. These algorithmsrely in part on a version of Stanford’s Java TheoremProver (JTP; 12) that we have integrated with KAoS.

4.1. Policy precedence conditions

Policy precedence conditions are needed to properlyexecute the automatic conflict resolution algorithm.When policy conflicts occur, these conditions are used todetermine which of the two policies being compared ismost important. The conflict can then be resolvedautomatically in favor of the most important policy.Alternatively, the conflicts can be brought to theattention of a human administrator who can make thedecision manually.

We currently rely exclusively on the combination ofnumeric policy priorities1 and update times to determineprecedence—the larger the integer and the more recentthe update the greater the priority. This is consistent withthe natural intuition that more recent and higher prioritypolicies should trump older and lower priority ones.

In the future we intend to allow people additionalflexibility in designing the nature and scope ofprecedence conditions. For example, it would bepossible to define precedence based on the relativeauthorities of the individual who defined or imposed thepolicies in conflict, which policy was defined first,which has the largest or smallest scope, whether negativeor positive authorization trumps by default, whethersubdomains takes precedence over superdomains or viceversa, and so forth.

4.2. Steps in policy conflict resolution.

The steps in order to resolve policy conflicts in theset of policies are as follow:

1. DAML policy ontologies are loaded into JTPalong with the set of DAML policies to bedeconflicted.

2. A list of all policies in constructed and sortedaccording to user-defined criteria for policyprecedence.

3. For each policy in the sorted list, iterate throughall the elements with a lower priority and checkto see if there is a policy conflict. A policyconflict occurs if the two policies are instancesof conflicting types and if a subsumption

1 In the absence of an explicitly rated priority, the priority valueof a policy may be “inherited” from the person who defined thepolicy or the priority of the controlled action class.

algorithm determines that the action classes thatthe two policies control are not disjoint.

4. The lower priority policy from the conflictingpair of policies is removed from the list and thepolicy harmonization algorithm is invoked. Itattempts to modify the policy with the lowerprecedence to the minimum degree necessary toresolve the conflict (if the policies are of equalprecedence, a user may be required to specifywhich policy will take precedence). Theharmonization algorithm may generate zero,one or several new policies to replace theremoved policy.

5. The newly constructed harmonized policiesinherit the precedence and the time of lastupdate from the removed policy, and a pointerto the original policy is maintained so that it canbe recovered if necessary as policies continue tobe added or deleted in the future.

4.3. Details of policy harmonization

Figure 3. Graphical representation of policyharmonization

The derivation of the newly-generated set ofharmonized policies can be understood by imagining anintersection of two N-dimensional Cartesian products:If P1 and P4 are two Cartesian products defined as:

P1 = D11 x D12 x …. x D1nP4 = D21 x D22 x …. x D2n

thenP1\P2 = subP1 + subP2 + … + subPn

where

subPk =(D11«D21) x ... x (D1(k-1)«D2(k-1))x (D1k\D2k) xD1(k+1) x .. x D1n

Figure 3 shows a 3-D graphical representation ofpolicy harmonization. Mapping the mathematicaldefinition above to the generation of harmonized policieswe get the following:

1. The first harmonized policy has a range ofactors that corresponds to the differencebetween the ranges of the two original policiesand a controlled action and range of values onthe action properties that correspond to those ofthe lower-precedence policy.

2. The second harmonized policy has a range ofactors that corresponds to the intersection of theranges of the two original policies, a controlledaction that corresponds to the differencesbetween those of the two policies, and a rangeof values on the action properties thatcorrespond to that of the lower-precedencepolicy.

3. Additional harmonized policies are built tocorrespond to each action properties in the twooriginal policies. The range of actorscorresponds to the intersection of the ranges ofthe two original policies and the controlledaction corresponds to the intersection betweenthose of the two policies.

The results of computing any of the above policiesmay be empty.

5. KAoS Policy and Domain Services

KAoS is a collection of componentized servicescompatible with several popular agent frameworks,including Nomads [18, 19], the DARPA CoABS Grid[14], the DARPA ALP/Ultra*Log Cougaar framework( h t t p : / / w w w . c o u g a a r . n e t ) a n d C O R B A(http://www.omg.org). While initially oriented to thedynamic and complex requirements of software agentapplications, the services are also being adapted tog e n e r a l - p u r p o s e g r i d c o m p u t i n g(http://www.gridforum.org) and web services(http://www.w3.org/2002/ws/) environments as well.The adaptability of KAoS is due in large part to itspluggable infrastructure based on Sun’s Java AgentServices (JAS) (http://www.java-agent.org). For a fulldescription of KAoS, the reader is referred to [4; 5; 6; 7].

Groups of people and computational entities arelogically structured into domains and subdomains tofacilitate policy administration. Domains may representany sort of group imaginable, from potentially complexorganizational structures to administrative units to

dynamic task-oriented teams with continually changingmembership. Membership in a given domain can extendacross host boundaries and, conversely, multipledomains can exist concurrently on the same host.Domains may be nested indefinitely and, depending onwhether policy allows, membership in more than onedomain at a time is possible.

KAoS domain services are not fully described in thispaper, however the following subsections describeKAoS policy services in more detail.

5.1. Initialization and Querying

During the bootstrapping process, the core policyontologies (KPO) are loaded into JTP. Afterwards,additional ontologies specific to a particular environmentor application can be loaded dynamically from the KAoSPolicy Administration Tool (KPAT; see section 5.2). Inaddition to a base set of policies, these additionalontologies usually include descriptions of domainstructures and the entities associated with them.

The policy service is configured to handle a varietyof queries at different stages of the policy managementprocess. Some of the more common ones are listedbelow.

Defining a new policy (or editing an existing one):1. Obtain all the action classes that can be

performed by either a given class of actors or agiven actor instance.

2. Obtain all the properties of a given action class.3. Obtain the range of targets for the property

applicable to the given action class.4. Obtain all the known subclasses of the Target

class within a given range.5. Obtain all the known instances of the Target

class within a given range.

Detecting policy conflicts:6. Check if two subclasses of the action class

controlled by two selected polices are disjoint.7. Check if the subclass of the action class

controlled by the policy with the lower priorityis a subclass of the subclasses of the action classcontrolled by the policy with the higher priority.

Harmonizing policies:8. Obtain the explicit superclasses of the action

classes controlled by the policies.9. Obtain the range of a property in the action

classes controlled by the policies.10. Check if the property in one controlled action

class is a subproperty of some properties in thesecond controlled action class.

Policies distribution and disclosure:11. Obtain all the policies whose controlled actions

can be performed by either a given class ofactors or a given actor instance.

12. Check if the given action instance is an instanceof some action class controlled by existingpolicies.

5.2. KAoS Policy Administration Tool (KPAT)

The KAoS Policy Administration Tool (KPAT2)implements a graphical user interface to domain andpolicy management functionality of KAoS. It has beendeveloped to make policy specification, revision, andapplication easier for administrators without extensivetraining (Figure 4).

Figure 4. KPAT notifies the user of the results ofpolicy harmonization

KPAT can be used to browse and load ontologies, todefine, deconflict, and commit new policies, and tomodify or delete old ones. The generic DAML PolicyEditor (Figure 5) is driven by the ontologies loaded intoJTP and always provides the user with the list of choicesnarrowed to the current context using the queriesenumerated in the previous subsection. Custom editorstailored to particular kinds of policies may also be addedto KPAT and triggered if a policy about the action classassociated with the given custom editor is selected.

When a user commits a change to an ontology (e.g.,a new or edited policy, changes to domain structure) theJena framework [11] is used to dynamically buildDAML representation based on the values selected bythe user.

2 Pronounced KAY-pat.

5.3. Policy distribution and disclosure

Figure 6 shows the major components of the KAoSpolicy and domain services architecture. KAoS DomainManagers (DM) act in the role of policy decision pointsto determine whether agents can join their domain andfor policy conflict resolution. The DM is responsible forensuring policy consistency at all levels of a domainhierarchy, for notifying Guards about changes in policyor other aspects of system state that may affect theiroperation, and for storing state in the directory service.

Because DM’s are stateless, one DM instance mayserve multiple domains or conversely, a single largedomain may require several instances of the DM toachieve scalable performance.

Policies are stored within ontologies in the directoryservice (DS). Although DM’s normally provide thelimited public interface to the DS, private interfaces mayallow the DS to be accessed by other authorized entities

in accordance with policies on disclosure.3 For example,trusted components could be allowed to perform queriesconcerning domain policies in advance of submitting aregistration request to a new domain. Because thepolicies in the directory service are expresseddeclaratively, some forms of analysis and verificationcan be performed in advance and offline, permittingexecution mechanisms to be as efficient as possible.

Guards are responsible for policy enforcementwithin the bounds of a specified computationalenvironment. They interpret policies that have beenapproved by the DM and enforce them with appropriatenative enforcement mechanisms. While KPAT and theDM, and the Guards are intended to work identicallyacross different agent platforms (e.g., DARPA CoABSGrid, Cougaar) and execution environments (e.g., JavaVM, Aroma VM), enforcement mechanisms arenecessarily designed for a specific platform andexecution environment.

3 We are investigating the work of Seamons [17] on incrementalpolicy disclosure strategies for future use in KAoS.

Figure 5. Generic DAML Policy Editor. Custom editors tailored to specific classes ofpolicy can also be easily developed.

Figure 6. KAoS Policy Service architecture

Whereas KAoS can currently represent anddeconflict both authorization and obligation policies, thecurrent implementation only supports enforcement forauthorization policies. In the near future, we will extendKAoS policy services with support for obligationpolicies through the use of monitors (monitoringcompliance with obligations) and enablers (facilitatingthe performance of selected obligations).

5.3.1 Enforcers Enforcers are the mechanism by whichGuards ensure compliance with authorization policies.The enforcer cannot be made fully generic, as it isinherently specific to the type or types of actions beingenforced by it and to the environment in which theseactions are being performed. What can be made generichowever is the interface to the system answering thequestion, “is a given action authorized or not?” Bydefining standard interfaces for answering this question,we aim to help enable developers to concentrate on theapplication-specific portions of the enforcers:

• intercepting the action being attempted by thecontrolled actors;

• creating an object with a description of theaction and calling the method with it asking forauthorization on the generic part of theenforcer;

• blocking or allowing the action based on theobtained result.

All of the capabilities of the policy services aremade fully available to the developer

In order to implement a new enforcer theprogrammer extends the provided class GenericEnforcerand implement its abstract methods:

• getControlledActionClasses - provides namesof the action classes on which policies can beenforced.

• initEnforcer - initializes the specific enforcercapabilities by inserting the triggering ormonitoring functionality into the computingenvironment (e.g., installing filters or resourceusage monitors).

The capability for interception action inserted by thei n i t E n f o r c e r method uses the methodi sAc t i onAu thor i z ed , which is provided by theGenericEnforcer superclass. The method takes as theparameter a description of the action, which includes:

• unique ID of the agent performing the action;• names of the Action classes describing the type

of the intercepted action instance consistentwith the ontologies;

• list of action property descriptions comprisingthe context of the action.

Each action property description requires the followinginformation:

• name of the property, consistent with theontology;

• indication of the form of the target description,which can be either the unique ID of the target(String), the DAMLModel (from Jena [11]) withtarget instance description, or opaqueapplication-specific data containing the instancedescription;

• actual data containing the target description inone of the forms indicated above.

It is the responsibility of the developer to understandthe definition of the action class(es) in the ontology thatthe enforcer is being designed to enforce. An action classcan be represented as a list of properties whose namesare in the ontology. By referencing a property using thisname the developer can determine the value of theproperty. We have developed a mapping tool, whichanalyzes a given ontology and generates the ontologynames as Java constants.

5.3.2 Enforcer repository Enforcer class names arerecorded in the Enforcer Registry. The registryassociates an enforcer class with the names of the actionclasses on which it can enforce policy.

The registry is either stored in a local Jar file or canbe made available on the network. When a particularenforcer is needed, a lookup is performed on the registry.If an enforcer is found, it can then be created through theJava Reflection mechanism.

Guards are responsible for creating instances of theenforcers they need to control the actions specified bypolicies it receives from Domain Managers. Of coursethis presumes that an appropriate enforcer is available inthe registry. The use of a registry allow for a dynamicextension of the system. Even when agents are running itis possibly to dynamically insert a new enforcer classinto a network-based Enforcer Registry so that new

policies about a class of actions controlled by thisenforcer can be defined. The list of actions shown inKPAT is limited to these for which there are enforcers inthe Enforcer Registry. In this way the system can preventattempts to put a policy in force for which there is noavailable enforcer.

5.3.3. Authorization mechanism As mentionedpreviously, the enforcer is concerned with getting theanswer to the question, “is a given action authorized ornot?” It is not so much concerned with how this answeris obtained. In the current KAoS implementation, it ispossible to answer the authorization question in one ofthree ways: through the use of the Directory Service,some intermediary module, or the enforcer itself.

For performance reasons, it is preferable to answerthe authorization question locally in the enforcer or anintermediary module whenever possible. In this wayenforcement can also continue even if the connection tothe Directory Service is interrupted. In such cases, theworst that could happen is that the DS will betemporarily unable to notify enforcers about policy-relevant changes to the ontology.

Every actor in the system is associated with a Guardthat is responsible for the computational environment inwhich it is running. When the guard receives a newpolicy, it obtains the types of actions controlled by thispolicy and checks to see if it already has an enforcer forthese action types. If not, it will consult the EnforcerRegistry and create the enforcer. When the appropriateenforcer is found, the policy is pushed to it. The genericenforcer’s policy storage object appropriately adds,removes or updates policies in its storage.

These policies are used by the isActionAuthorizedmethod. When the method is executed, it traverses theenforcer policy storage and checks to see if the givenaction instance is in the range of actions controlled byany policy (the range of actions is defined by the actionclass associated with a policy). This can be checked byinvestigating all of the action properties. Each propertyhas to be checked to assure that the value assigned to thisproperty in the action instance description is in the rangeof this property defined in the action instance descriptionby the appropriate restriction class. The enforcer can getdifferent forms of the description of the instance.

When the DS already knows about the instance, itsunique id can be provided. This is the case of anyconcepts defined in the preloaded ontologies orexplicitly registered in the directory (e.g., actors ,domains). In this situation, the enforcer has eitheralready cached the set of instances from its range (whichit obtained from the DS), or can obtain this set directlyand then easily check to see if the instance is within theset. There are ways to tailor the performance of this

mechanism, depending whether this set is dynamic orstatic.

Sometimes the instance is new. For example, it mayhave just been created in the context of the action, as isoften the case in message content filtering, where thecontent can be very diverse and the description complex.In these cases, the description of the target instance hasto be built dynamically, and two options of passing it tothe authorization mechanism exist. We can use eitherDAMLModel object (from Jena) if it is possible toanalyze the value of the property or if it is alreadyencoded in DAML, or else we can use opaqueapplication-specific data containing the instancedescription.

5.3.4. Semantic matching Semantic matching isperformed by the authorization mechanism by itslooking into the Semantic Matcher Repository todetermine if there is a matcher associated with the givenaction property name. Each matcher in the repositoryimplements the same interface containing methods to:

• initialize the specific semantic matcher forinstance loading necessary ontologies, and soforth;

• check to see if the instance from the provideddescription is of the type indicated by the nameof the provided ontology class.

5.3.5. Handling partial action description Situationssometimes arise when an enforcer is able to provide onlypartial information about the intercepted action. In suchcases, the following approach is applied. If the action hasa given property and the description of the action ismissing the value for this property then the algorithmassumes that it matches the property range in the case ofnegative authorization policies or does not match in thecase of positive authorization policies.

The rationale for doing this is that, in the case ofnegative authorization, since we do not know the valuewe cannot exclude the possibility that it was in the givenrange. To be on the safe side we assume, therefore, thatit was in the range. Similarly, in the case of positiveauthorization, since we cannot exclude the possibilitythat the value was out of range, we assume that it wasindeed out of range. Further experience will tell uswhether these assumptions should be made to hold in allapplications.

Additionally, the algorithm can investigatesubproperties relations. For instance, an actiondescription may lack the value for some property P. If,however, a value is defined for some subproperty orsuper-property of the property P then this value maybetaken into account. This aspect requires further study andexperimentation.

5.3.6 Default authorization When the authorizationmechanism does not find any policy applicable to theprovided action instance, it still must answer theauthorization question. Hence, the need for a defaultauthorization modality for enforcers that either permitsall actions not explicitly forbidden or else forbids allactions not explicitly permitted.

The current way of configuring the defaultauthorization modality is on a per domain basis. Eachdomain can have one default authorization: negative orpositive. In order to resolve potential conflicts, when anagent is registered in more than one domain, a domaincan have an associated priority. When a guard registersitself in various domains, it receives the defaultauthorizations from them. If they are in conflict, theguard selects the default coming from the domain withthe highest priority. Then it passes this default to itsenforcers.

We will investigate more flexible means ofconfiguring default authorization modalities once moresophisticated precedence mechanisms that go beyondcurrent numeric priority schemes are in place.

5.4. Policy enforcement mechanisms

In applications to date, we have relied on severaldifferent kinds of enforcement mechanisms.Enforcement mechanisms built into the executionenvironment (e.g., OS or Virtual Machine levelprotection) are the most powerful sort, as they cangenerally be used to assure policy compliance for anyagent or program running in that environment, regardlessof how that agent or program was written. For example,the Java Authentication and Authorization Service(JAAS) provide methods that tie access control toauthentication. In KAoS, we have in the past developedmethods based on JAAS that allow policies to be scopedto individual agent instances rather than just to Javaclasses. Currently, JAAS can be used with Java VMs; inthe future it should be possible to use JAAS with theAroma VM as well. As described above, the Aroma VMprovides, in addition to Java VM protections, acomprehensive set of resource controls for CPU, diskand network. The resource control mechanisms allowlimits to be placed on both the rate and the quantity ofresources used by Java threads. Guards running on theAroma VM can use the resource control mechanisms toprovide enhanced security (e.g., prevent or disabledenial-of-service attacks), maintain quality of service forgiven agents, or give priority to important tasks.

A second kind of enforcement mechanism takes theform of extensions to particular agent platformcapabilities. Agents that participate in that platform aregenerally given more permission to the degree they areable to make small adaptations in their agents to comply

with policy requirements. For example, in applicationsusing the DARPA CoABS Grid, we have defined aKAoSAgentRegistrationHelper to replace the defaultGridAgentRegistrationHelper. Grid agent developersneed only replace the class reference in their code toparticipate in agent domains and be transparently andreliably governed by policies currently in force. On theother hand, agents that use the defaultGridAgentRegistrationHelper do not participate indomains and as a result they are typically granted verylimited permissions in their interactions with domain-enabled agents.

Finally, a third type of enforcement mechanism isnecessary for obligation policies. Because obligationscannot be enforced through preventive mechanisms,enforcers can only monitor agent behavior and determineafter-the-fact whether a policy has been followed. Forexample, if an agent is required by policy to report itsstatus every five minutes, an enforcer might be deployedto watch whether this is in fact happens, and if not toeither try to diagnose and fix the problem, oralternatively take appropriate sanctions against the agent(e.g., reduce permissions or publish the observedinstance of noncompliance to an agent reputationservice). In the near future, we plan to develop monitorsand enablers to allow the full use of obligation policies.

Each policy has a property that defines the site ofpolicy enforcement. For example, access control policiesare typically enforced by a mechanism directlyassociated with the resource to be protected (i.e., thetarget). However in some cases, administrators may nothave control over this resource and instead may requirethe policy to be enforced by a mechanism associatedwith the actor (i.e., the subject) or some other entityunder their purview.

5.5. Performance of the current system

We have tested the performance of KAoS policyconflict resolution algorithms on a machine withPentium III 1.2 GHz and 640 MB RAM using JDK1.3.1. In the limited non-optimized tests we have madeto date, policy commitment, conflict resolution, andharmonization is consistently performed in a fraction ofa second. For reasons that are not yet fully understood,however, assertion of each new policy into the JTPdatabase typically takes an order of magnitude longerthan that. Stanford JTP developers are currently workingon performance improvements that should significantlyaffect these results.

6. Example applications

KAoS policy and domain services are beingextended and evaluated in the context of severalapplications.

The first application is the DARPA CoABS-sponsored Coalition Operations Experiment (CoAX)(http:// www.aiai.ed.ac.uk /project/ coax/) [1; 20]. CoAXmodels military coalition operations and implementagent-based systems to mirror coalition structures,policies, and doctrines. The project aims to show that theagent-based computing paradigm offers a promising newapproach to dealing with issues such as theinteroperability of new and legacy systems, the implicitnature of coalition policies, security, and recovery fromattack, system failure, or service withdrawal. KAoSprovides mechanisms for overall management ofcoalition organizational structures represented asdomains and policies, while Nomads provides strongmobility, resource management, and protection fromdenial-of-service attacks for untrusted agents that run inits environment.

Within the DARPA Ultra*Log program(http://www.ultralog.net) we are developing agent policyand domain services to assure the robustness andsurvivability of logistics functionality in the face ofinformation warfare attacks or severely constrained orcompromised computing and network resources.

Another application is within the NASA Cross-Enterprise and Intelligent Systems Programs, where weare investigating the use of policy-based models to drivehuman-robotic teamwork and adjustable autonomy forhighly-interactive autonomous systems such as thePersonal Satellite Assistant (PSA), a softball-sized flyingrobot that is being designed to operate onboardspacecraft in pressurized micro-gravity environments[6]. The same approach is also being generalized for usein other testbeds, such as unmanned vehicles and otherhighly interactive autonomous systems.

Under funding from DARPA's AugmentedCognition Program, we are taking this approach one stepfurther as we investigate whether a general policy-basedapproach to the development of cognitive prostheses canbe formulated, where human-agent teaming could be sonatural and transparent that robotic and software agentscould appear to function as direct extensions of humancognitive, kinetic, and sensory capabilities [3; 9].

7. Current limitations and future work

We are continuing research and development toaddress various limitations of the currentimplementation. The ontology and reasoning does notyet adequately support reasoning about compositeactions or processes and relations between fine-grain

actions and composed by them high-level actions. Weplan to add foundational support for composition ofabstract, high-level policies from simple policies throughthe concept of policies sets. Under funding from theDARPA DAML program, we are also working incollaboration with Austin Tate to investigate howDAML-S (http://www.daml.org/services/) may addresssome of these issues.

Another limitation is our current ad hoc approach toconditional policies through the use of a policy conditionmonitor. In the coming year, we plan to investigate theuse of DAML-R/RuleML for this purpose. We also planto deal more adequately with the temporal aspects ofpolicy through incorporation of the DAML-Timeontologies.

Additional future work will include full support forobligation policies, performance enhancements toreasoning mechanisms, simplification and streamliningof the KPAT user interface, transition from DAML toOWL, and policy implementation constraint resolutionto deal with policies involving contention for finiteresources. We will also continue in our efforts to developversions of KAoS suitable for deployment in WebServices and Grid Computing environments.

Acknowledgments

The authors gratefully acknowledge the sponsorshipof this research by the NASA Cross-Enterprise andIntelligent Systems Programs, and a joint NASA-DARPA ITAC grant. Additional support was providedby DARPA’s CoABS, Ultra*Log, DAML, andAugmented Cognition programs, and by the ArmyResearch Lab’s Advanced Decision Architecturesprogram (ARLADA). We are grateful for thecontributions of Alessandro Acquisti, PatrickBeautement, Guy Boy, Marshall Brinn, Murray Burke,Mark Burstein, Marco Cavalho, Bill Clancey, TomCowin, Rob Cranfill, Naranker Dulay, Paul Feltovich,Rich Feiertag, Richard Fikes, Ken Ford, Mark Greaves,Jack Hansen, Robert Hoffman, Wayne Jansen, JessicaJenkins, Mike Kerstetter, Mike Kirton, Emil Lupu,Deborah McGuinness, Sheila McIlraith, NicolaMuscettola, Anil Raj, Tim Redmond, Sue Rho, DylanSchmorrow, Mike Shafto, Maarten Sierhuis, MorrisSloman, Austin Tate, Ron Van Hoof, and Tim Wright.

References

[1] Allsopp, D., Beautement, P., Bradshaw, J. M.,Durfee, E., Kirton, M., Knoblock, C., Suri, N., Tate, A.,& Thompson, C. (2002). Coalition Agents eXperiement(CoAX): Multi-agent cooperation in an internationalcoalition setting. A. Tate, J. Bradshaw, and M.Pechoucek (Eds.), Special issue of IEEE IntelligentSystems, 17(3), 26-35.[2] Berners-Lee, T., Hendler, J., & Lassila, O. (2001).The semantic Web. Scientific American, 284: 5 (May),34-43.[3] Bradshaw, J. M., Beautement, P., Raj, A., Johnson,M., Kulkarni, S., & Suri, N. (2002). Making agentsacceptable to people. In N. Zhong & J. Liu (Ed.),Handbook of Intelligent Information Technology. (inpreparation). Amsterdam, The Netherlands: IOS Press.[4] Bradshaw, J. M., Dutfield, S., Benoit, P., & Woolley,J. D. (1997). KAoS: Toward an industrial-strengthgeneric agent architecture. In J. M. Bradshaw (Ed.),Software Agents. (pp. 375-418). Cambridge, MA: AAAIPress/The MIT Press.[5] Bradshaw, J. M., Greaves, M., Holmback, H., Jansen,W., Karygiannis, T., Silverman, B., Suri, N., & Wong,A. (1999). Agents for the masses: Is it possible to makedevelopment of sophisticated agents simple enough to bepractical? IEEE Intelligent Systems (March-April), 53-63.[6] Bradshaw, J. M., Sierhuis, M., Acquisti, A.,Feltovich, P., Hoffman, R., Jeffers, R., Prescott, D., Suri,N., Uszok, A., & Van Hoof, R. (2002). Adjustableautonomy and human-agent teamwork in practice: Aninterim report on space applications. In H. Hexmoor, R.Falcone, & C. Castelfranchi (Ed.), Agent Autonomy. (inpress). Kluwer.[7] Bradshaw, J. M., Suri, N., Breedy, M. R., Canas, A.,Davis, R., Ford, K. M., Hoffman, R., Jeffers, R.,Kulkarni, S., Lott, J., Reichherzer, T., & Uszok, A.(2002). Terraforming cyberspace. In D. C. Marinescu &C. Lee (Ed.), Process Coordination and UbiquitousComputing. (pp. 165-185). Boca Raton, FL: CRC Press.Expanded version of an article originally published inIEEE Intelligent Systems, July 2001, pp. 49-56.[8] Damianou, N., Dulay, N., Lupu, E. C., & Sloman, M.S. (2000). Ponder: A Language for Specifying Securityand Management Policies for Distributed Systems,Version 2.3. Imperial College of Science, Technologyand Medicine, Department of Computing, 20 October2000.[9] Ford, K. M., Glymour, C., & Hayes, P. (1997).Cognitive prostheses. AI Magazine, 18(3), 104.[10] Greaves, M., Holmback, H., & Bradshaw, J. M.(2001). Agent conversation policies. In J. M. Bradshaw(Ed.), Handbook of Agent Technology. (in preparation).Cambridge, MA: AAAI Press/The MIT Press.

[11] Jena, http://www.hpl.hp.com/semweb/[ 1 2 ] J T P – J a v a T h e o r e m P r o v e r ,http://www.ksl.stanford.edu/software/JTP/[13] Kagal, L., Finin, T. & Joshi, A. (2001). ADelegation-based Distributed Trust Model for MultiA g e n t S y s t e m s , u n d e r r e v i e w ,http://www.csee.umbc.edu/~finin/papers/aa02/[14] Kahn, M., & Cicalese, C. (2001). CoABS GridScalability Experiments. O. F. Rana (Ed.), SecondInternational Workshop on Infrastructure for ScalableMulti-Agent Systems at the Fifth InternationalConference on Autonomous Agents. Montreal, CA, NewYork: ACM Press,[15] Knoll, G., Suri, N., & Bradshaw, J. M. (2001). Path-based security for mobile agents. Proceedings of theFirst International Workshop on the Security of MobileMulti-Agent Systems (SEMAS-2001) at the FifthInternational Conference on Autonomous Agents (Agents2001), (pp. 54-60). Montreal, CA, New York: ACMPress,[16] Lupu, E. C., & Sloman, M. S. (1999). Conflicts inpolicy-based distributed systems management. IEEETransactions on Software Engineering,—Special Issueon Inconsistency Management, 25(6), November/December, 852-869.[17] Seamons, K. E., Winslet, M., & Yu, T. (2001).Limiting the disclosure of access control policies duringautomated trust negotiation. Proceedings of the Networkand Distributed Systems Symposium.[18] Suri, N., Bradshaw, J. M., Breedy, M. R., Groth, P.T., Hill, G. A., & Jeffers, R. (2000). Strong Mobility andFine-Grained Resource Control in NOMADS.Proceedings of the 2nd International Symposium onAgents Systems and Applications and the 4thInternational Symposium on Mobile Agents (ASA/MA2000). Zurich, Switzerland, Berlin: Springer-Verlag,[19] Suri, N., Bradshaw, J. M., Breedy, M. R., Groth, P.T., Hill, G. A., Jeffers, R., Mitrovich, T. R., Pouliot, B.R., & Smith, D. S. (2000). NOMADS: Toward anenvironment for strong and safe agent mobility.Proceedings of Autonomous Agents 2000. Barcelona,Spain, New York: ACM Press,[20] Suri, N., Bradshaw, J. M., Burstein, M. H., Uszok,A., Benyo, B., Breedy, M. R., Carvalho, M., Diller, D.,Groth, P. T., Jeffers, R., Johnson, M., Kulkarni, S., &Lott, J. (2002). DAML-based policy enforcement forsemantic data transformation and filtering in multi-agentsystems. (submitted for publication).