Using RDF for policy specification and enforcement - CiteSeerX

Using RDF for policy specification and enforcement Barbara Carminati1, Elena Ferrari1, Bhavani Thuraisingham2 1 Università dell’Insubria, Como, Italy {barbara.carminati, elena.ferrari}@uninsubria.it 2 National Science Foundation, USA [email protected]

Abstract Security issues for the Resource Description Framework (RDF) [RDF] are today crucial due to the key role played by RDF for the semantic web [LEE01]. However, despite its importance, RDF security is still a novel area and very little work has been done so far. In this paper, we make a first step in this direction by first discussing the main issues in RDF security. Then, we consider one of the aspect of RDF security, by proposing an approach for using RDF for policy specification and enforcement.

1. Introduction Resource Description Framework (RDF) [RDF] is the specification developed by the World Wide Web Consortium for specifying various resources, ontologies and concepts on the web. RDF uses the syntax of XML [XML] and consists of many features to express the semantics of an entity, event, or relationship. Essentially RDF has become the foundation of what is knows as the semantic web. The semantic web is a web that is intelligent with machine-readable web pages. The goal is to automate various activities on the web without human intervention. The idea of the semantic web was conceived by Tim Berners Lee. In his book on weaving the web, he explains his ideas on going from the web to the semantic web [LEE99]. Perhaps one of the best articles on the semantic web was published by Berners Lee, Hendler, et al., in Scientific American in May 2001 [LEE01]. The authors explain clearly how with the semantic web, agents are able to effectively carry out all operations from coordinating the activities to keeping appointments and schedules. Today we are operating in an environment that is very insecure with Trojan horses, viruses and worms. Daily we hear about security breaches on the Internet. As the web

evolves into the semantic web, there are more and more possibilities for security breaches as we introduce new technologies. Therefore, it is critical that the security be considered right from the beginning when we develop the semantic web. To secure the semantic web, we need to secure all its components such as XML, RDF, Agents, Databases, Web Services, and Ontologies and ensure the secure interoperation of all these technologies. Security research for the semantic web is just at the beginning. While we have some work carried out in securing XML documents [G00], secure agents, secure databases and secure web services, there is virtually no work on RDF security we well as secure information interoperability. This paper describes our preliminary investigation on RDF security. In particular, we provide an overview of the main issues in the field. Basically, we can distinguish between two main issues: that of securing RDF documents and that of using the semantic richness of RDF for expressing security information and for making policy specification and enforcement easier. In this paper, we focus on this latter issue, by showing how RDF can be used for policy specification. The organization of this paper is as follows. Section 2 surveys related work. Section 3 provides some background information on RDF. Section 4 discusses various aspects of RDF security, whereas Section 5 shows how RDF can be used for making easier the specification and enforcement of access control policies. Finally, Section 6 concludes the paper by outlining future research directions.

2. Related Work RDF security is a novel research area and thus very little work has been done so far. To the best of our knowledge the only work dealing with RDF security is the one by [GOW03]. The authors propose a framework for enforcing access control on XML documents, which allows a security classification of XML nodes, and associations among nodes. The main feature of this approach is, thus, the possibility to express associationbased restriction on the access, whereas the only point of contact with RDF is due to the fact that they exploit RDF to express security information (i.e., security policy and

association among XML node). The main difference between the strategy in [GOW03] and our is that we do not limit to use the RDF data model to express security policy, by contrast we exploit RDF model to allow the specification of high level policy on a general scenario, and to automatically entail all the implied authorizations for a specific scenario. By contrast, there has been considerable work on XML security (see for example [G00] for an up-to-date overview of what is going on in the area). Since RDF specification relies on XML specification, XML security is essential for securing RDF documents. Therefore, in what follows we summarize some of the work on XML security and then, in Section 4 we ask some questions relevant to RDF security. Work in the field of XML Security have mainly focused on the development of access control models specifically tailored to the characteristics of XML documents [BERT02, DAM00]. Such work have resulted in the development of very flexible access control models that provide support for fine-grained and content-based access control and for policies either on a single document or on a DTD/XMLSchema. Moreover, they provide support for the notion of subject credential, and for a number of advanced features for authorization propagation and exception management Additionally, [BERT03] addresses the problem of secure publishing of XML documents on the web. The idea proposed in [BERT03] is that of exploiting a third-party architectures in which information owners publish documents, subjects request access to the documents, and publishers give the subjects the views of the documents they are authorized to see. The idea is how to ensure the authenticity and confidentiality requirements of both the owner and the subjects even in the presence of an untrusted publisher. Essentially, the owner specifies the access control policies. The publisher will then enforce the access control policies and sends the subjects additionally information that make them able to verify the authenticity of the information they receive. Encryption algorithms as well as Merkel hash trees are used to ensure the security properties (we refer the interested reader to [BERT03] for more details). Other related work are currently carried in standardization committees. For instance, the W3C is specifying standards for XML security. The focus is on XMLSignature Syntax and processing, XML-Encryption Syntax and Processing and XML Key Management. W3C also has a number of working groups including XML Signature working group and XML encryption working group. By contrast, the OASIS Consortium is actually developing XACML (eXtensible Access Control Markup Language) a standard language for expressing access control policies in XML. The language provides a very general and high level framework for policy specification which supports the specification of role-based access

control policies and the possibility of grouping several access control rules into a single policy.

3. A Brief Introduction to RDF RDF (Resource Description Framework) is a key component of the semantic web, since it provides a standardized way to describe resource and their relationships. RDF is essentially the foundation for processing metadata. While XML is limited in providing machine understandable documents, RDF handles this limitation. That is, while XML provides syntax and notations, RDF supplements this by providing semantic information in a standardized way As a result, RDF provides better support for interoperability as well as searching and cataloging. RDF is the work of many communities collaborating together to represent metadata in a standardized way. These communities include the Web Standardization Community as well as those working on XML, HTML, SGML and other related standards. The basic RDF data model is built on the concepts of resources, properties and statements, which can be represented by means of an intuitive and simple graph model. The term resource denotes anything that can be identified by an URI reference [URI], which not necessarily implies a web resource. For instance, a resource could be a web page or a collection of pages, as well as, a person or an organization. In the graph model the resource is designed by an node containing the corresponding URI reference. An information of the resource can be expressed by way of the property. The property denotes an attributes or a characteristics of the resource. As example, a property could be the date of creation of a web page, as well as the author of the page. The properties are associated with resources by means of the property-types, expressed by a URI reference, which are graphically designed as an arc connecting the resource with the corresponding property value. More precisely, the property-types state the relationships between an atomic values and the associated resources (i.e., the atomic property), as well as relationships with other resources, which in turn may have their own properties. The RDF statements can be expressed, thus, as the resources together with their property plus the value of the property. Moreover, a set of RDF statements describing a common scenario is referred to as an RDF description. As example, Figure 1 depicts the RDF description stating that the document identified by http://www.pm.org/docs/WebPage_1 has been created in data 26/03/04, by the administrative staff having ID equal to 134. The RDF working groups have defined an formal syntax for representing the graph model into a machine-readable

http://www.pm.org/docs/WebPage_1 http://www.pm.org/PM-schema/property#data_creation http://www.pm.org/PM-schema/property#author

03/26/04

http://www.pm.org/people/Administrative_staff

http://www.pm.org/PM-schema/property#ID

134

Figure 1 An example of RDF description

files. More precisely, it provides an XML syntax [RDFSYNTAX] for formalizing the concepts of resource, properties and sentence.

4. RDF Security The relationship between RDF and security could be analysed from several perspectives, which give rise to different issues that must be taken into account. In what follows, we provide an overview of the main issues related to RDF security. The first issue is related to the fact that the ultimate goal of RDF is to provide an highlevel and semantic rich description of web resources and their relationships (i.e., properties). So the issue is how we can exploit the RDF description of a given domain to specify access control policies over them and, more generally, relevant security information for the considered domain. Essentially what we need is to propose extensions to RDF to specify security policies. Similar work has been carried out for XML security (see for example, [BERT02]). In Section 4 we discuss some preliminary directions toward such a specification. Note that RDF was developed mainly for the semantic web. Semantic web is essentially about machine readable web pages [LEE01]. The semantic web is composed of multiple layers including XML and RDF layers. For the semantic web to be useful for many applications, we need to ensure that it operates securely. Now to make the semantic web secure, we need to ensure that RDF documents are secure. This would involve securing XML from a syntactic point of view. However with RDF we also need to ensure that security is preserved at the semantic level. The issues include what the security implications of the concepts resource, properties and statements. That is, how is access control ensured? How can statements and properties be protected? How can one provide access control at a finer level of granularity? What are the security properties of the container model? How can bags, lists and alternatives be protected? Can we specify security policies in RDF? How can we resolve

semantic inconsistencies for the policies? How can we express security constraints in RDF? What are the security implications of statements about statements? How can we protect RDF schemas? These are difficult questions and we need to start research to provide answers. XML security is just the beginning. Securing RDF is much more challenging. Semantic web must also ensure the interoperability between databases and diver information sources. In addition to the information management components, the semantic web also consists of a collection of web services. RDF has been used to specify the ontologies necessary for interoperability between information sources as well as for operation of web services. Ontologies specify various information sources and services. These ontologies may be used to specify the security policies also. These security policies need to be integrated so that one can formulate a policy for the semantic web. This means that the security policies specified in RDF need to be integrated so that an integrated policy can be formed for the semantic web. Therefore, the use of RDF for the secure interoperability between information sources and services is also another direction for investigation. As we have stated in Section 2, there has been considerable work on securing XML documents including the secure publishing and dissemination of XML documents. Thus, we need to investigate the applicability of the techniques developed for XML documents to RDF documents. In addition, we need to explore the use of encryption techniques as a way to ensure the secure distribution of RDF documents. Since RDF is involved with the semantics of documents, we need to explore additional mechanisms for the secure publication and dissemination of RDF documents. This section has listed multiple aspects that need to be investigated in order to explore the relationships between security and RDF. In the following section, we explore the use of RDF to specify security policies as well as enforcing access control.

5. Using RDF for access control policy specification and enforcement Policy specification is the first step in defining a system able to protect any web resource. Access control policies are basically high level rules regulating how access control should take place. An example of access control policy can be the rule stating that: “Only the creator of a data object can modify it”. The definition of the policies usually results by the analysis, carried out by the Security Administrator (SA) or the owner of the data, of

http://www.pm.org/PM-schema/resources#project_Manager

http://www.pm.org/PM-schema/property#chief-of -

http://www.pm.org/PM-schema/resources#Administrative_staff http://www.pm.org/PM-schema/property#level http://www.pm.org/PM-schema/property#manage

http://www.pm.org/PM-schema/property#chief-of

http://www.pm.org/PM-schema/resources#Technical_staff

-

http://www.pm.org/PM-schema/property#creator

Value http://www.pm.org/PM-schema/resources#Technical_Report

http://www.pm.org/PM-schema/resources#Funds

http://www.pm.org/PM-schema/property#Amount

Value

http://www.pm.org/PM-schema/property#Date -

Value

Figure 2 An RDF description for a general domain the security requirements of the scenario being protected. Traditionally, such policies are expressed in natural language, without any kind of formalization. Thus, in order to make the access control mechanism able to enforce the specified policies, each policy is implemented as a set of authorizations, that is, a set of tuples (s, o, m), stating that subject s can access object o under access mode m. When a subject submits an access request to the system, the access control mechanism verifies whether the access can be granted or not by searching among the specified authorizations. The main drawback of this traditional approach, is the lack of tools that help the SA in the policy specification process. We have languages (e.g., SQL for RDBMSs) for specifying authorizations, but there is lack of tools that help the SA in the specification of policies and in generating the corresponding authorizations starting from the specified policies. For instance, it would be nice to have a tool for specifying policies for a general scenario (e.g., the management of research projects) and then to generate, starting from this high level policies, the set of corresponding authorizations for a particular instance o this scenario (e.g., the authorizations regulating the management of research projects for a specific organization). As an example, consider again the policy above introduced, stating that: “Only the creator of a data object can modify it”. This general policy can be instantiated in several contexts. For instance, if we apply it to a medical scenario, data objects can be patient records or medical prescriptions. Thus, examples of entailed authorizations can be (Dr Smith, patient_record123, modify). By contrast, if we consider the same policy applied to technical reports issued by a university, then examples of entailed authorizations can

be: (Professor E. Ferrari, TR#78, modify) or (Dr. B.Carminati, TR#76, modify). These simple examples show the need of policy specification tools that consider only the high level semantics of the involved resources and their relationships, leaving out the details of the particular scenario. In this paper, we make a step in this direction, by showing how RDF can help the policy specification task and the deployment of the specified policies in different scenarios (that is, the generation of the authorizations entailed by the policies). More precisely, we show how RDF can be exploited in two different phases of the authorization generation process: the first is the specification of the access control policies for a general scenario, hereafter called high level policies, whereas the second is the generation of the authorizations for a specific scenario, starting from the high level policies and an RDF description of the considered domain. In the following sections, we consider both these two phases. Before going into the details, we provide a general overview of our approach.

5.1 Overall strategy The idea underlying our approach is that of using RDF to provide an high level description of different scenarios with similar characteristics, that is, scenarios with similar resource types and semantic relationships among them, and with similar security requirements. Moreover, we use RDF also to specify policies on such general scenario. To better clarify our approach, we use as running example a general scenario for the management of research projects. Figure 2 depicts part of the RDF description for such a scenario. The main resources in the

RDF description of general scenario + Security req.

SA

high level policies generator

Security enhanced RDF description

analysis

High level policies generation

High level policy base RDF description of specific scenario

Authorizations entailment Authorizations (s,o,m)

Reference Monitor

Figure 3 The overall architecture considered scenario are: Project Manager, Administrative Staff, Technical Staff, Funds, and Technical Reports. According to the RDF data model, each resource has associated a set of properties, with atomic values (e.g., the Amount property for the Funds resource, the organization level of the Administrative staff), or properties representing relationships between two resources. With reference to Figure 2, an example of property modelling a relationship is the property “chiefof” between Project Manager and Administrative Staff/Technical Staff. A further example of this kind of property is the property “manages” between Administrative Staff and Funds, and “creator” between Technical Staff and Technical Reports. The high level scenario depicted in Figure 2 is general enough to denote a set of more specific scenarios, all conforming to such a general template, which we call scenario instances. On the RDF description of Figure 2, we can define general policies applying to all the scenario instances. An example can be the policy stating that the fund resources must be managed only by the administrative staff. The basic idea of our approach is that from the RDF description of a general domain, the SA is able to define high level policies for that domain, which are then applied to all the domain instances to derive the set of entailed authorizations. Once the high level policies for a general domain are specified on its RDF description, and given the RDF description of a specific scenario conforming to that domain, the proposed framework is able to automatically entail all the authorizations implied by the application of

the high level policies on the specific scenario. The overall architecture of our framework is depicted in Figure 3. The key components of the architecture are the following modules: “High level policy generation”. Given the RDF • description of the general scenario, the goal of this module is the specification of the corresponding high level policies. More precisely, the first step is the analysis carried out by the SA on the RDF general description. During the analysis, the SA specifies access control constraints for the general domain. In particular, as it will be explained in the next section, this module helps the SA in defining the access control constraints directly on the RDF description, generating thus the so-called "Security-enhanced RDF description". Starting from this document, the module automatically generates the corresponding policies. • “Authorizations entailment”. In order to enforce the high level policies specified on the general domain, it is necessary to generate the corresponding authorizations for the specific scenario instance being considered. This task is carried out by the "Authorization entailment" module, which takes as input the RDF description of a scenario instance and the high level policies generated in the previous phase, and generates all the corresponding authorizations.

http://www.pm.org/PM-schema/resources#project_Manager http://www.RDFsec.org/RDFsec#role http://www.pm.org/PM-schema/property#chief-of

http://www.pm.org/PM-schema/property#chief-of

subject

http://www.pm.org/PM-schema/resources#Administrative_staff http://www.pm.org/PM-schema/property#level http://www.pm.org/PM-schema/property#manage http://www.RDFsec.org/RDFsec#role

http://www.pm.org/PM-schema/resources#Technical_staff

-

http://www.pm.org/PM-schema/property#creator

http://www.RDFsec.org/RDFsec#role

Value subject

http://www.pm.org/PM-schema/resources#Funds

http://www.pm.org/PM-schema/property#Amount http://www.RDFsec.org/RDFsec#role

Object

Value

subject

http://www.pm.org/PM-schema/resources#Technical_Report

http://www.pm.org/PM-schema/property#Date http://www.RDFsec.org/RDFsec#role

Value

Object

http://www.RDFsec.org/RDFsec#accessRights

http://www.RDFsec.org/RDFsec#accessRights

(level>5, amount>1000K, modify) (,, (modify, cancel))

Figure 4 The security enhanced RDF description •

“Reference monitor”. Such module is in charge of access control. It receives as input an access request and checks whether there exists an authorization authorizing the requested access. In such a case, the access is granted; otherwise, it is denied.

In the following sections, we explain the strategies underlying the two main phases, that is, the high level policy generation and the authorization entailment

5.2 High level policy generation The first step to generate high level access control policies for the general scenario is the SA analysis of the security requirements. More precisely, starting from the RDF description of a general domain, the SA (or the data owners) has to specify, on the RDF description itself, the access control policies for that domain. In particular, in our approach high level policies can be formalized as tuples of the form (class of subjects, class of objects, set of access modes), where class of subjects/objects are the resources appearing in the RDF description of the general scenario, and access modes denote the operations that the class of subjects can perform on the class of objects. It is interesting to note that such kind of policies are particularly suited for scenarios where all the subjects identified by the same RDF resource (i.e., for instance, all the subjects belonging to the administrative staff) have the same access control rights on all the objects

denoted by another RDF resource (i.e., all the funds of the project). For instance, with the policy format introduced above it is not possible to express the access control rule “All the funds with amount greater than 1000k have to be managed only by administrative staff belonging to a level higher than 5”. In order to make our policy format able to express this kind of access control rules, we extend our basic format with the possibility of expressing constraints on the subject and object properties. This is quite easy according to our approach, since in our RDF description of the general scenario a class of objects/subjects coincide with a resource described in the RDF description. Thus, properties on which access control policies can be based are the corresponding atomic property-type of the considered resources. In such a case, access control policies are formalized by means of tuples of the form: (class of subjects, class of objects, set of access mode specifications). In particular, this last term is a set of tuples of the form (cond_subj, cond_obj, set of access modes), which specifies that subjects belonging to the class of subjects and respecting the condition cond_subj can access under the set of specified access modes the objects belonging to the class of objects in the policy and respecting the condition cond_obj. Referring to the policy defined above, it can be formalized by the tuple: (http://www.pm.org/PM-schema/resources#Administra tive_staff,http://www.pm.org/PM-schema/resources# Funds, (level>5, amount=>1000k, {modify,read})).

Bob http://www.w3.org/2000/10/swap/pim/contact#fullName http://www.w3.org/2000/10/swap/pim/contact#Person

Patty http://www.w3.org/2000/10/swap/pim/contact#fullName

http://www.pm.org/PM-schema/resources#project_Manager

http://www.pm.org/PM-schema/property#belongs

http://www.w3.org/2000/10/swap/pim/contact#Person

http://www.pm.org/PM-schema/property#chief-of

………………

http://www.pm.org/PM-schema/property#chief-of http://www.RDFsec.org/RDFsec#belongs

Alice http://www.w3.org/2000/10/swap/pim/contact#fullName

http://www.pm.org/PM-schema/resources#Administrative_staff

http://www.w3.org/2000/10/swap/pim/contact#Person

http://www.pm.org/PM-schema/property#level

Ann

294 http://www.pm.org/PM-schema/resource#account

http://www.pm.org/PM-schema/property#chief-of -

http://www.pm.org/PM-schema/property#manage

6

http://www.RDFsec.org/RDFsec#belongs

http://www.pm.org/PM-schema/property#bank

http://www.w3.org/2000/10/swap/pim/contact#fullName

http://www.pm.org/PM-schema/resources#Funds http://www.RDFsec.org/RDFsec#belongs

http://www.pm.org/PM-schema/resources#Administrative_staff http://www.pm.org/PM-schema/property#Amount

http://www.w3.org/2000/10/swap/pim/contact#Person

http://www.RDFsec.org/RDFsec#belongs http://www.pm.org/PM-schema/property#level http://www.pm.org/PM-schema/property#manage http://www.pm.org/PM-schema/property#manage

4

1500K

09327 http://www.pm.org/PM-schema/resource#account

http://www.pm.org/PM-schema/property#bank

http://www.pm.org/PM-schema/resources#Funds

http://www.pm.org/PM-schema/resources#Funds

http://www.pm.org/PM-schema/property#Amount

http://www.pm.org/PM-schema/property#Amount

http://www.RDFsec.org/RDFsec#belongs

698

1500K

200K http://www.RDFsec.org/RDFsec#belongs

http://www.pm.org/PM-schema/resource#account http://www.pm.org/PM-schema/property#bank

Figure 5 An RDF description of a specific domain

Thus, the SA has to specify the class of subjects, the class of objects, and the corresponding access specifications for each policy it would like to enforce. To do that, we suppose that all resources of the RDF model, that is, objects uniquely identified by an URI, can play both the role of the subject and object of a policy. Thus, given an RDF description of a general scenario, the SA can assign to all the resources a role either of subject or object. For instance, considering the example in Figure 2, the resources ‘Technical Staff’ and ‘Technical report’ play the role of subject and object, respectively. To keep track of the role that each resource plays, according to the SA directives, the RDF description of the general domain is extended, by associating with each resource an atomic property-type “role”, with value “subject” or “object” (see Figure 4). Once the class of subjects and the class of objects of an high level policy have been specified, the SA has to state the access mode under which that class of subjects can access that class of objects, and, optionally, conditions on the subject and object properties. To model such information, the security-enhanced RDF description is complemented with a new atomic property-type “access rights” that can be associated with all the resources playing the role of object. The value of such property models the (cond_subj, cond_obj, p) component of a policy. Upon the end of the policy specification phase, the component “High level policy generator” parses the security-enhanced RDF description and automatically derives the corresponding high level policies, which are then stored in the “High level policy base” in the form (class of subjects, class of objects, set of access mode specifications).

5.3 Authorization Entailment The Authorization Entailment module receives as input

the RDF description of a specific scenario, that is, the scenario instance, and starting from it and from the high level policies it generates all the authorizations implied by the policies for the specific scenario. In order to understand the underlying process, it is first necessary to better clarify the structure of the scenario instance. The goal of the scenario instance is to provide a detailed description of a specific scenario, conforming to the RDF description of the general domain of which it is an instance. This detailed description consists of one or more copies of the resources and properties in the RDF description of the general domain, plus some additional information referring to the instances of each resource. With the term instance of a resource we denote a subject/object of a specific domain belonging to the class of subjects/objects denoted by the resource in the general domain description. For instance, with reference to Figure 2, given the resource administrative staff, the instances are the specific persons that in the considered domain belong to the administrative staff. As an example, let us consider as domain instance of the RDF description in Figure 2, the management of a research project for a given organization (see Figure 5). This scenario contains two copies of the administrative staff resource, corresponding to staffs with different organization levels (i.e., level 6 and 4). Moreover, each administrative staff has associated the corresponding instances, modelling the specific subjects which belong to the administrative staff (i.e., Bob and Patty belonging to the administrative staff with level 6, Ann and Alice belonging to the administrative staff with level 4). More formally, we assume that an RDF description R_inst is a scenario instance of an RDF description R_dom, if the following conditions hold: S R_inst contains one or more copies of each resource and property described in R_dom S R_inst preserves the relationships among resources and properties defined in R_domfor each resource R in R_inst corresponding to a

resource in R_dom; let inst(R) be the set of instances of R in the specific domain. Then, for each r∈ inst(R), R_inst contains a corresponding resource connected to R by the property-type “http://www.RDFsec.org/RDFsec#belongs”. We are now ready to describe the authorization entailment process. The process iteratively considers the high-level policies defined for the general domain and computes the set of entailed authorizations for the scenario instance being considered. An algorithm performing such task is reported in Figure 6. For the sake of simplicity, we consider only policies with a single access mode specification. The algorithm we present can, however, be easily extended for considering more than one access mode specification. The algorithm takes as input a scenario instance R_inst, an high level policy hlp, and the authorization base AB, and it returns the updated authorization base, containing the authorizations entailed by the input policy. The algorithm derives the implied authorizations by iteratively considering each copy of a resource playing the role of subject, with the corresponding copy of the resource playing the role of object. More precisely, the algorithm inserts into the authorization base a new authorization (s, o, am), where s is an instance of the copy of the resource playing the role of subject in the input policy, o is an instance of the copy of the resource playing the role of object in the input policy, and am are the access modes in hlp. In particular, the algorithm inserts a different authorization for each different

instance of the copy of a resource playing the role of subject/object in the policy. In the algorithm we use the dot notation to denote the various components of a policy. Thus, given the high level policy hlp, hlp.class_of_subj and hlp.class_of_obj denotes the URI contained in the subject and object specification, respectively; whereas hlp.access_spec denotes the set of tuples (cond_subj, cond_obj, set_of_access_modes) contained in the access mode specification of the policy. The algorithm in the first steps computes the set of copies of the resources playing the role of subject (object) in the high level policy. This is done by extracting from R_inst all the resources with URI equal to hlp.class_of_subj (hlp.class_of_obj), and by pruning from this set all those resources not satisfying the condition expressed in the access mode specification (i.e., hlp.access_spec.cond_subj/.cond_obj). In step 3, the algorithm iteratively considers each copy of the resources playing a subject role, whereas in the inner cycle (3.a) it considers each copy of the resources playing an object role and connected to the subject resource iterated. Moreover, in order to insert a different authorization for each different instance of the copy of the resource playing the role of subject/object, in steps 3.a.i and 3.a.i.1 the algorithm iterates each instance of the copy of subject /object resource. These instances represents the subject s and the object o of the new authorization. Finally, for each different access modes specified in hlp.access_spec.set_of_access_modes the algorithm inserts a new authorization with this values as access modes, and the s and o as subject and object.

Algorithm 5.1: The authorization Entailment INPUT: R_inst: the domain instance hlp: an high level policy applied to R_inst AB: the authorization base OUTPUT updated Authorization Base 1.

let copies_subj be the set of resources in R_inst with URI equal to hlp.class_of_subj and satisfying the condition in hlp.access_spec.cond_subj 2. let copies_obj be the set of resources in R_inst with URI equal to hlp.class_of_obj and satisfying the condition in hlp.access_spec.cond_obj 3. For each cs∈ copies_subj : a. For each co∈ copies_obj connected with cs : i. For each s∈Inst(cs) 1. For each o∈Inst(co) a. For each am ∈ hlp.access_spec.set_of_access_modes i. add (s, o, am) to AB End For 4.

Return AB

Figure 6 The authorization entailment algorithm

As an example of algorithm execution, consider the high level policy hlp=(http://www.pm.org/PMschema/resources#Administrative_staff, http://www.pm.org/PM-schema/resources# Funds, {(level>5, amount=>1000k, {modify, read})}), and the scenario instance in Figure 5. The first steps of the algorithm determine from hlp the URI(s) of the resources playing the role of subjects and objects. By using these URI(s) the algorithm determines the copies of the corresponding resources in the scenario instance, which satisfy the condition stored in the access mode specification. Referring to domain instance in Figure 5, the only copy of the resource identified by the URI http://www.pm.org/PM-schema/resources# Administrative_staff and satisfying condition “level>5” is the administrative staff with level 6. Whereas, the copies of the resource identified by the URI http://www.pm.org/PM-schema/resources#Funds and satisfying condition “amount=>1000k” are the two funds with amount 1500k. For each copy of the subject resource the algorithm determines the corresponding copies of objects. Referring to Figure 5, the algorithm considers the resource associated to the administrative staff with level 6, and the fund with amount greater than 1500k connected to it. In step 3.a.i, the algorithm considers each instance cs of the subject resource determined in step 3. Then, for each instance co of the object resource (determined in 3.b.i) and for each access mode am specified in the access mode specification, the algorithm adds the authorization (cs, co, am) to the authorization base. In our running example, the instances of the resource associated with the administrative staff with level 6 are Patty and Bob, whereas the only instance of the resource associated to fund with amount 1500k is the fund in the banking account 09327. Thus, the inserted authorizations are (Patty, account09327, modify), (Patty, account09327, read), (Bob, account09327, modify), (Bob, account09327, read).

6. Summary and Directions This paper has explored the relationships between RDF and security. Since RDF uses XML syntax, we first discussed the developments on securing XML documents. Next, we provided some background on RDF. Note that RDF was developed mainly for making the web more intelligent. Therefore RDF security is a key aspects of securing the semantic web. We also discussed the relationship between security and RDF. Specifically, we mentioned four aspects. One is to use RDF for specifying security policies; the second is to ensure access control for RDF documents, the third is to investigate the use of RDF for the secure interoperability of resources and

services on the web, and finally to develop techniques for the secure publications and dissemination of RDF documents. Finally we explored some details on the first two aspects. That is, we discussed some approaches for specifying policies using RDF and then we discussed access control on RDF documents. While the ideas discussed in this paper are preliminary, to our knowledge we are the first to discuss such ideas. We need to develop the ideas further. For example, in Section 5 we described a security architecture. We need to carry out a detailed design of the various components of the architecture. We need to essentially work with the RDF standards organizations (e.g., W3C) and incorporate policies specification into the standards. We also need to explore the enforcement of access control and other policies on RDF documents. We also need to expand on our other ideas mentioned in Section 4. Specifically, we need to explore the use of RDF in secure interoperability as well as develop techniques for publishing and disseminating RDF documents. We believe that the semantic web is a reality and to make it operational we need to ensure that it operates securely. Therefore, investigating the relationships between RDF and security is critical for developing a secure semantic web. There are many challenging research problems in this area.

7. References [RDF-SYNTAX] Beckett D. (Editor). RDF/XML Syntax Specification (Revised). W3C Recommendation, 10 February 2004, http://www.w3.org/TR/rdf-syntaxgrammar/. [LEE99] Berners-Lee T., Fischetti M., and Dertouzos M. Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web by its Inventor. Hardcover [LEE01] Berners Lee T., et al., The Semantic Web, Scientific American, May 2001. [URI] Berners-Lee T., Fielding R., Masinter L. RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax. IETF, August 1998, http://www.isi.edu/innotes/rfc2396.txt. [BERT02] Bertino E., and Ferrari E., Secure and selective dissemination of XML documents, ACM Transactions on Information and System Security (TISSEC), 5(3): 290--331, 2002. [BERT03] Bertino E., Carminati B., Ferrari E., Thuraisingham B. and Gupta A. Selective and Authentic

Third-party Distribution of XML Documents. To appear in IEEE Transactions on knowledge and Data Engineering (TKDE), 2003. [XML] Bray T., Paoli J., Sperberg-McQueen C.M., Maler E. (Editors). Extensible Markup Language (XML) 1.0, Second Edition, World Wide Web Consortium, 6 October 2000, http://www.w3.org/TR/REC-xml [DAM00] E.Damiani, S.De Capitani di Vimercati, S.Paraboschi and P.Samarati. Securing XML Documents. In Proceedings of the of the International Conference on Extending Database Technology (EDBT2000), Konstanz, Germany. [FER01] Ferraiolo D., Sandhu R., Gavrila S., Kuhn D., Chandramouli R.. Proposed NIST standard for rolebased access control. ACM Transactions on Information and System Security (TISSEC). 4(3): 224-274, 2001. [G00] Geuer Pollmann C. The XML Security Page. http://www.nue.et-inf.uni-siegen.de/~geuerpollmann/xml_security.html [GOW03] Gowadia V., and Farkas C. RDF Metadata for XML Access Control. ACM workshop on XML Security, October, 2003, Fairfax, VA, USA. [RDF] Manola F., and Miller E. (Editors). RDF Primer. W3C Recommendation 10 February 2004 http://www.w3.org/TR/2004/REC-rdf-primer-20040210/