Securing Systems Intelligently: The Logical

Approach

Brian Shields and Owen Molloy

National University of Ireland Galway, Department of Information Technology,

brian.shields@geminga.it.nuigalway.ie, owen.molloy@nuigalway.ie

Abstract The quantity of generated information we store and need to access is

colossal. Security of this information is becoming an issue of greater importance
as the techniques and granularity with which it can be accessed become more ad-
vanced. Availability of information is a key component of any security system, al-
though the information must be protected, it must also be available to the people
who need it as and when they request it. However, increasing the methods by
which it is accessible automatically increases the chance it may be compromised.
Security systems are now using advanced levels of encryption, digital signatures
containing biometric data and highly complex access control policies. We are pro-
posing a security framework with an access control system which reduces the
complexity involved in defining authorisation permissions, particularly in struc-
tured documents such as XML where the user may be granted restricted access.
Our solution employs techniques usually reserved for intelligent systems and the
semantic web.

1 Introduction

An organisation often has a need to share information securely with members of

that organisation, or indeed members of another organisation. The definition of
what ‘securely’ means can cause some consternation among certain groups of
people. Access control is the area of security in which our work lies. Access
control has been a large area of study for years, with more effort being applied
to it re- cently inline the growth of online information systems, the increase in
data which
is protected and the increase in the number of users, authorized or otherwise.
RBAC has become the most widely used method of defining and enforcing
access control in information systems since its inception in 1995 (Sandhu et al.,
1996). RBAC works on the premise that role groups exist in the system; it then
controls access of information with respect to these groups. To access information
a user must be a member of a role and assume the authorisation privileges of that
role.

C. Barry et al. (eds.), Information Systems Development: Challenges in Practice, Theory, 753
and Education, Vol.2, doi: 10.1007/978-0-387-78578-3_13,
© Springer Science+ Business Media, LLC 2009
75 Brian Shields and Owen Molloy
4
In a typical RBAC system, the individual roles are granted access to resources.
Resources can be processes or information. Each relevant file must be accounted
for in the role permissions, if it is not then it is usually assumed that role lacks the
appropriate permissions to access the file. With the development and now wide-
spread adoption of XML as an information representation, particularly in Web
environments, the task of permission assigning has become extensively more diffi-
cult. There is a large body of research investigating XML access control, which
will be discussed in Section 6. All of this work proposes different ways of grant-
ing and restricting access to individual attributes and element of the XML file. In a
large system this can increase the security workload exponentially.
This chapter proposes another solution to this problem. A solution we regard
as reducing a lot of the time-intensive activities of assigning role permissions to
the elements and attributes of an XML file. We present a way of writing rules
which will determine the permissions for each role. This activity is carried out at a
schema level, yet different permissions may be assigned to alternative documents,
or document elements, of the same schema. Most XML access control systems re-
quire the user to specify permissions at both a schema and instance level as, after
all, a role may have permissions to access one document and not another, yet both
are instances of the same schema. For example, a doctor may access one patient
record and not another, while both patient records have the same schema.
We propose an intelligent authorisation system that can decide the permissions
for an individual at the time they request information. We use description logic
and decidable rules to provide the necessary intelligence for this. In this chapter
we apply this system to the Electronic P atient Record (EP R) from the area
of Health Informatics.
This chapter is organised as follows. Section 2 provides an overview of the
two main technologies: description logics and rules. Section 3 is an overview of
our security framework including a detailed description of our system architecture.
Section 4 presents our access control system, the main components involved and
how they interact with one another. Section 5 explores some related research in
XML access control. We conclude the chapter and detail some potential future
avenues for our research in Section 6.

2 Overview of Technologies

In this chapter we propose the use of some less well-known technologies as part of
our authorisation system. In this section we attempt to introduce two research areas:
description logic and rules or rule-based systems. We then present the application
of these research areas which we apply to our work, the Web Ontology Language
(OWL) (McGuinness & van Harmelen, 2004) and the Semantic Web Rule
Language (SWRL) (Horrocks et al., 2004), respectively.
 Securing Systems Intelligently: The Logical Approach 75
5
2.1 Description Logic

Description logic is a family of logic-based knowledge representation (KR) for-

malisms. Description logic is a descendant of semantic networks and KL-ONE
and describe a domain in terms of concepts, roles and individuals. Concepts have
also been referred to as classes, roles as relationships and individuals as instances.
Description logic has two key characteristics:
Formal Semantics – which are decidable fragments of First Order Logic (FOL)
Inference Services – which in turn provide decision procedures

The architecture of a typical DL system is composed of two principal compo-

nents: a knowledge base and an inference or reasoning engine. The knowledge
base consists of two types of knowledge:
Tbox – or terminology box is the schema or description of the knowledge. It
contains the hierarchical structure of the data and relationships between its con-
cepts
Abox – or assertion box is actual data. It is instance information of the concepts
described in the TBox

OWL, or the Web Ontology Language, is a web standard as specified in the

World Wide Web Consortium (W3C) Recommendation of February 2004. OWL
is built on top of Resource Description Framework (RDF) and is written in XML.
It is based on description logic and has three sub languages:
OWL Full – is the union of OWL Syntax and RDF
OWL DL – is restricted to the FOL fragment. OWL DL is fully decidable
OWL Lite – is the “easier to implement” subset of OWL DL
OWL DL benefits from the years of research into description logic. It has well
defined semantics. Its formal properties, such as complexity and decidability, are
well understood by the DL community. There are many known DL reasoning
algorithms and highly optimised implemented systems that can be easily applied
to OWL DL.

2.2 Rules

Rules are becoming an increasingly important part of business information sys-

tems. They abstract some of the business logic from the core software components
of the system and therefore make it easier to develop the system, but more impor-
tantly they allow the relatively straightforward update or modification of the
business logic. This can now become the task of an analyst familiar with the rule
language,
75 Brian Shields and Owen Molloy
6
rather than that of the developer who wrote the system. This is one of the reasons
we have decided to represent our access control logic in the form of rules.
There are four main types of rules used in rule systems:
Derivation or deduction
Transformation rules
Integrity constraints
Reaction or Event-Condition-Action (ECA)

For the purpose of our system, and most logic systems, we will be exclusively
using derivation or deduction rules. The nature of this type of rule is to examine
certain information and assert new information based on its findings.
The number of rule languages available today is getting larger. According to
Tim Berners-Lee’s semantic technology stack (Berners-Lee, 2000), rules are the
next step in knowledge engineering systems. We have chosen Semantic Web Rule
Language (SWRL) as the language in which to represent our rules. SWRL is a
combination of the OWL and the work done by the RuleML community. It extends
OWL by adding simple Horn style rules. A rule of this nature states that if the
antecedent, or ‘if part,’ of the rule is true then the consequent, or ‘then part,’ of the
rule must also hold true. SWRL is a W3C proposed standard.

3 F ramework Architecture

Although a security solution such as this is almost completely composed of or

related to access control, there are a number of other services which must be in
place to offer a complete security framework. These services include a Key
Management Service, an Encryption and Decryption Service and a Framework
Management Service.
Figure 1 shows the proposed architecture of the proposed security framework
which will be discussed in the remaining part of this section.

3.1 Key Management Service

The security framework will provide a service which will create, manage and store
X.509 digital certificates. These certificates will be used as security tokens in
requesting SOAP message headers to provide a non-repudiative user identity.
The Key Management Service will be designed and implemented using the
XKMS (XML Key Management Specification) Standard from OASIS (Ford et al.,
2001). This provides two principle services:
XML Key Information Service Specification (XKISS) – This service locates a
public key in order to encrypt information for an individual or to verify signed
information.
 Securing Systems Intelligently: The Logical Approach 75
7
XML Key Registration Service Specification (XKRSS) – This provides a
number of services to register, recover, reissue and revoke keys

In addition to implementing the services specified in XKMS, the security

framework will store keys locally in order to reduce the interruption time between
users requesting a service and when that service is called. Keys for new users will
be registered or created through the Framework Management Service.

F ig. 1. P roposed Security Framework Architecture

3.2 E ncryption and Decryption Service

In addition to protecting information while in storage, the Security Framework

must enforce a strict security policy on the confidentiality of information while
‘on the wire.’ All communication between remote clients and the Security Frame-
work will be encrypted by the sender; be that the client or the framework. The de-
signers of the Web Service endpoints may specify additional encryption policies.
The Encryption and Decryption services will be exposed services from the en-
cryption/ decryption engine. This engine will encrypt and decrypt information
ac- cording to a public key. If UserA makes a Web Service request to a Web
Service managed by the Security Framework, the SOAP request is, at the very
least, en- crypted using our public key. The request will be subj ect to first tier
authorisation (detailed in section 4); upon successful authorisation, the message
will be fully decrypted by the encryption/ decryption engine, using our private
key, and passed
75 Brian Shields and Owen Molloy
8
to second tier authorisation. The response returned to the requester is encrypted
using their public key which is located using the Key Management Service.

3.3 F ramew ork Management Service

The Framework Management Service will be a HTTP and SOAP

management centre used by the administrators of the Security Framework. It is
essentially a front-end management of the different components of the
framework. It will have five principal responsibilities:
Uploading and registering or creating new keys
Register valid Web Service endpoints
Create/ edit/ remove access control policies
Add/ remove/ edit users and semantic user
descriptions Add/ remove/ edit semantic resource
descriptions.

4 Access C ontrol Model

Figure 2 is an architecture diagram of our proposed access control solution. This

architecture has two fundamental areas: design-time components and runtime
components. Both of these areas have access to our reasoning engine. We are
using Hoolet as our reasoning engine.
The design time components include all the modules which are involved in
preparing and customising the solution for a particular domain or problem. It has
three components: an Ontology Loader, a Schema Mappings Engine and a Rule
P arsing Engine. The Ontology Loader accepts an OWL-DL ontology as an
XML file, verifies if it is consistent and loads it into the reasoning engine. The
Schema Mappings Engine parses an XML mappings file which provides our
authorisation system with knowledge of the structure of XML files. The Rule P
arsing Engine receives and parses an XML file containing access control rules
written in SWRL. These rules are made available to the reasoning engine at
runtime.
The runtime components of our authorisation system include all the modules
involved in making an access control decision on a client request for information
and enforcing this decision. The system will use these components to decide what
parts of the requested XML file will be made available to the requesting client,
and then prune the file appropriately. There are three components in this section of
our system: an Instance Mapping Engine, and Instance Q uery Engine and an
XML P runing Engine. The Instance Mapping Engine uses the previously
defined schema mappings to map each element and attribute to their
counterparts in the ontology. The Instance Q uery Engine takes each element and
attribute of the XML file and queries the reasoning engine about the access
control levels for it, as
 Securing Systems Intelligently: The Logical Approach 75
9
possessed by the requesting client. The XML P runing Engine uses the results
of these queries to prune any element or attribute to which the requesting client
lacks the appropriate access.

4 .1 Design T ime

From Figure 2 we can see that the architecture of our system is composed of two
distinct areas. This section attempts to explain the first of these sections, design
time. The section has three parts, each one dealing with one of the components of
the design time area; ontology design, access control rules specification and XML
Schema to OWL DL mappings.
Before we can begin reasoning about access to the information system, we
must first develop an ontology representing the information stored. There are six
steps which we use to create the ontology:

F ig. 2. Access Control Module Architecture

1. D etermine the scope – The ontology for our system must include any in-
formation which can be shared with users.
2. R euse ex isting ontologies – If any of the information in the scope
has been previously defined in an ontology then this can be imported and
re- used.
76 Brian Shields and Owen Molloy
0
3. D efine the classes and class hierarchy – The concepts of the domain are
specified. In our example we have the classes Medic, Surgeon, Nurse,
ClinicalInformation, etc. These are then organised into a hierarchical
structure by specifying relationships between them. We use three general
relationships for creating the ontology hierarchy: subsumtion, disj oint
and equivalent.
4. D efine the properties of the classes – Classes alone will not
provide enough information. Once the main concepts are represented by
classes we must define the internal structure of these concepts. Two
types of properties may be defined: Obj ectP roperties which relate two
classes to each other and DatatypeP roperties which are common simple
types such as integer and string.
5. D efine the facets of the properties – The property facets refer to
the property type, cardinality and possible legal values it may store.
6. C reate instances – Once the ontology is designed, instances of each
class must be created. Each of these instances is referred to as an obj ect
of its class.

One of the most important functions of an access control system, second only
to their enforcement, is the design and deployment of the access control rules.
There is a module in our system architecture called the ‘Rule P arsing Engine.’
This module accepts rules, written in SWRL, parses them for correctness and
completeness, and loads them into the reasoning engine for later assertion. We use
deduction rules (also called derivation or ‘if-then’ rules) in our access control sys-
tem. Deduction rules, as described in section 3, present a number of assertions (an-
tecedent), all of which must be true for the resulting assertion (consequent) to be
true. All rules in our system currently have a consequent ‘hasAccessToInforma-
tion(p, o)’ where p is some defined user of the system and o is the obj ect they have
access to. ‘hasAccessToInformation’ is an OWL Obj ect P roperty. It is defined in
our ontology as having a domain of ‘P erson’ and a range of ‘Information.’ This is
read ‘P erson hasAccessToInformation Information.’ This can be explained further
by example. The following rule says that a doctor may access the details of a pa-
tient if he/ she is the treating physician of that patient.

Doctor(?p) ^ Patient(?o) ^ treats(?p, ?o)

hasAccessToInformation(?p,?o)

Doctor and P atient are OWL classes as defined in our ontology. ‘Doctor(?
p)’ asserts that the variable p is an instance of Doctor. ‘treats’ is an OWL Obj ect
P roperty and is defined in our ontology as having the Doctor class as its
domain and a range P atient. ‘treats(? p, ? o)’ asserts that the instance p and the
instance o are a legal domain and range of the obj ect property. In keeping with
the nature of deduction rules, if the three assertions on the antecedent, or left
side, of the rule are true, then our reasoning engine will verify that the assertion
on the consequent,
 Securing Systems Intelligently: The Logical Approach 76
1
or right side, of the rule will also hold true. In reality, rules in a health care system
would be far more complex, and therefore we have developed some more multi-
farious examples. One such example is:

Medic(?x) ^ Medic(?y) ^ TestRequest(?a) ^

TestResult(?b) ^ supervises(?y, ?x) ^
requestedBy(?a, ?x) ^ hasResult(?a, ?b)
hasAccessToInformation(?x, ?b)

which reads: A medic has access to results of all tests requested by anyone they
supervise.
The ontology or ontologies defining the elements of the system do j ust
that, define the elements of the system and their relationships to one another. This
must now be linked in some way to the data structures that pass in and out of the
system so the access control rules can be applied to it. For example, using our
EP R, we must take each individual element from it and tell the security engine
what that element means in terms of our ontological description of our
system. Naming conventions can be an issue as one hospital system may call j
unior doctor medics where another hospital may call them interns. These
differences become irrelevant as long as they are mapped to the appropriate item
in the ontology. The mappings take place from the schema of the XML file in
question. Schema to ontology mappings or XSD to OWL mappings have
received a lot of interest recently. One can create a mapping from the schema to
the ontology which will hold true for all XML instances of that schema which
may be created. Three types of mappings ex- ist: Class Mappings, Obj ect P
roperty Mappings and Datatype P roperty Mappings.
Class Mappings are mappings between elements or attributes of the XML file
and OWL DL Classes from the ontology. The snippet of XML in Listing 1 is an
example of a simple Class Mapping. We noticed when designing the mapping
module of our security engine that OWL classes often mapped to parent elements
in the XML schema, i.e. ‘class elements’ contained only child elements, they did
not contain any text element or attributes. Therefore in order to uniquely identify
an obj ect of this class mapping when an XML file is presented, we allow the
user to specify data from somewhere else in the XML file to act as the identifier.
The unique identifier must be an ancestor of the class element in question and is
identi- fied using an XP ath expression.
Obj ect P roperty Mappings are mappings between elements or attributes of
the XML file and OWL DL Obj ect P roperties from the ontology. Listing 2
contains an example of a simple obj ect property mapping. As with the class
mappings, obj ect property mappings must specify the element of the XML
Schema which is being mapped and the obj ect property in the ontology it is
being mapped to. We must also specify the appropriate domain and range of the
obj ect property, this is neces- sary for some complex assertions about an
individuals access rights. Listing 2 shows that the XML item in question is
being mapped to ‘madeBy’ obj ect prop- erty of the ontology. It is important to
specify that we mean the ‘madeBy’ prop- erty from the statement that
‘ClinicalObservation madeBy Medic’ as the obj ect property ‘madeBy’ can exist with
other domains such as ‘ClinicalDirection.’
76 Brian Shields and Owen Molloy
2
Datatype P roperty Mappings are the mappings between elements or
attributes of the XML file and OWL-DL Datatype P roperties of the ontology.
Listing 3 con- tains an example of a simple datatype property mapping. Datatype
property map- pings are the least complex of the three mappings. They contain
three elements, the element of the XML Schema which is being mapped, the
datatype property from the ontology it is being mapped to and the type of the
property, i.e. string, int, etc. Datatype properties will be leaf elements or
attributes in the XML file. They are used when providing temporal access control
for the data.

4 .2 Runtime

This section explains the processes involved in the runtime area of the system ar-
chitecture of our system as seen in Figure 2. There are three areas which we cover
in this section: the compilation of XML Mappings from our Schema mappings in
the previous subsection, formatting and executing queries on our access control
system and pruning the XML document before it is sent to the requesting client.
We explained in the previous subsection how the XML Schema to OWL Map-
pings are created and used. This alone would have been sufficient to provide the
access control of a basic RBAC system. We can restrict access according to the
group or role a person belongs to. However, in this section we describe how to
further specify this access control. To achieve this we must be able to reason on
the instance information and not on general concepts. When an XML file is re-
quested and is awaiting return, its appropriate schema mapping configurations are
loaded. The XML file is then parsed and the instance information added to the
mappings. Care is needed when parsing instance information. The XML file is ac-
cessed for the information according to XP ath information supplied in the
map- pings configuration.

< ClassMapping>
< xmlItem> P atientRecord/ P atientInformation< / xmlItem>
< owlItem> P atientInformation< / owlItem>
< identifiedBy> P atientRecord/ P atientInformation/ idNum< / identifiedBy>
< / ClassMapping>

Listing 1 – Class Mapping

< Obj ectP ropertyMapping>

< xmlItem> P atientRecord/ ClinicalInformation/ ClinicalObservation/ madeBy< / xmlItem>

< owlItem> madeBy< / owlItem>
< domain> ClinicalObservation< / domain>
< range> Medic< / range>

Listing 2 – Obj ect P roperty Mapping

 Securing Systems Intelligently: The Logical Approach 76
3

< DatatypeP ropertyMapping>

< xmlItem> P atientRecord/ P atientInformation/ idNum< / xmlItem>
< owlItem> ID_ num< / owlItem>
< type> string< / type>
< / DatatypeP ropertyMapping>

Listing 3 – Datatype P roperty Mapping

In our example, we have the XP ath expression ‘/ patientRecord/

clinicalInformation/ observation/ idNum.’ According to the schema of our EP R,
we can have multiple ‘observation’ elements and therefore we need to ensure we
are parsing the correct ‘idNum.’ This is important as the requesting client may
have access to some ‘observation’ elements and not others. Using instance
information in our reasoning engine will allow us specify tighter access control
rules such as
‘A doctor may only access the information of a patient in his direct care.’ Usually,
to achieve this level of control, it is necessary to provide instance information in
the access control rules.
Once the instance mapping is complete we have our own obj ect structure
rep- resenting the XML file. Each element and attribute is represented by one
obj ect. This obj ect contains information on the element such as name, value,
type (which comes from the schema) and a mapping to its counterpart in the
ontology. From these obj ects we can create individual queries which we send to
the reasoning en- gine. A Semantic Access Control Q uery is a triple
(individual1, property, individ-
ual2), where: individual1 is the user trying to access information; property1 is
always the OWL Obj ect P roperty hasAccessToInformation; is the
individual2
instance information the user is trying to access. For example, ‘surg123 hasAc-
cessTo p12345.obs123)’ is querying the reasoning engine whether the surgeon
surg123 has access to the information of the observation obs123 of patient
p12345. The reasoning engine will return ‘yes’ or ‘no.’ This result is stored in out
XML item representative obj ect and will be used when pruning the XML file.
Any alterations made to an XML file at runtime can prove troublesome, espe-
cially when the file must satisfy a schema. The first action of the pruning engine is
the alteration of the XML Schema file. The level of restriction of the schema must
be addressed. All cardinality of elements and attributes within complex element
structures are changed to ‘0 or more.’ This will ensure that, after pruning, an XML
file is still of valid structure, according to its schema. The root node of the XML
file is retrieved. In a depth first traversal of the tree, each XML node is examined
for pruning. On selection of an element or attribute, the pruning engine finds
the corresponding obj ect representation in our system and gets the result from
the query execution. If the result was ‘yes,’ the node is passed over and the next in
the tree is selected. If the result was ‘no’ the XML item is removed from the
XML file. If the item is an element, all children are also removed. Once all
elements and attributes have been examined and removed if necessary, the
authorisation system returns the document to the Web service response and lets it
continue as normal.
76 Brian Shields and Owen Molloy
4
5 R elated W ork

There has been much work done in the area of fine-grained access control of XML
documents. Bertino et al. (1999), Damiani et al. (2000) and Kudo et al. (Kudo &
Hada, 2000) all present ways of securely accessing XML documents at an element
level.
Damiani et al. (2004) describe a means of providing access control, enriched
with semantics, of resources by extending existing policy languages. They present
an extension to XACML (XACML Technical Committee, 2005) which enables
the specification of users and resources in terms of ‘rich ontology-based meta-
data.’ This approach successfully achieves access control to resources in the tradi-
tional sense, i.e. files and processes.
Q u et al. (2004) propose OREL, an ontology based Rights Expression
Lan- guage (REL) to control a users rights to access digital content. They
essentially add reasoning capabilities to existing RELs such as XrML.
Q in et al. (Q in & Atluri, 2003) define a model for access control
for the semantic Web based on concept definitions. Access control decisions are
at a con- cept level as defined in an OWL ontology. They describe the benefits of
a seman- tically rich access control model in terms of the reduction of
administration efforts in updating the authorisation policies. Although they do
present an intelligent, rich access control model, they apply it to semantic
concepts as defined on a Web page. It is not applied to XML documents.
Xiaopeng et al. (2005) present an access control model for grid computing
which uses semantic descriptions. They describe the entities of the system and the
access control policies in the Semantic P olicy Language and then use
semantic reasoning to determine access rights and resolve potential conflicts.
This applica- tion of semantic access control is exclusively applied to grid
resources.
Agarwal and Sprick (2004) (Agarwal et al., 2004) and Y ague et al. (Y
ague & Troya, 2002; Y ague et al., 2003) provide us with examples of how they
ensure ac- cess control for semantic Web services.
Our work is trying to achieve a lot of what has been discussed in this section,
although we are trying to merge it all together. We provide semantic access con-
trol of XML documents, and we provide it to an element level of granularity.

6 C onclusions and F uture W ork

We have proposed an intelligent solution to XML access control which we believe

will dramatically reduce the workload involved in authorisation administration. As
each new schema is added to the system a mapping file is also added. No authori-
sation details have to be added for either schema or instance as access control is
enforced on the underlying information rather than the document itself.
Work has already started in creating an ontology, including some sample in-
stance information, for the Health Level 7 (HL7) information standard. HL7 is the
 Securing Systems Intelligently: The Logical Approach 76
5
standard for information transfer in the health domain
mitted to completing in our system include temporal- and geographical-based ac-
cess control using SWRL builtins; the addition of a secure update facility for the
XML documents; testing alternative reasoning engines for increased reasoning
speed; and a more intelligent querying system which will use knowledge of the
document structure to reduce the number of queries executed.

R eferences

Agarwal, S. & Sprick, B. (2004) Access Control for Semantic Web Services. IEEE
International Conference on Web Services. San Diego, CA.
Agarwal, S., Sprick, B. & Wortman, S. (2004) Credential Based Access Control for
Semantic Web Services. In 2004 AAAI Spring Symposium Series, Stanford, CA.
Berners-Lee, T. (2000) Keynote Address. XML 2000. http:/ / www.w3.org/ 2000/ Talks/
1206- xml2k-tbl/ slide10-0.html.
Bertino, E., Castano, S., Ferrari, E. & Mesiti, M. (1999) Controlled Access and Dissemination
of XML Documents. 2nd ACM Workshop on Web Information and Data Management.
Kansas City, MO.
Damiani, E., Capatini di V imercati, S., Fugazzo, C. & Samarati, P . (2004) Extending P
olicy Languages to the Semantic Web. International Conference on Web Engineering.
Munich Germany.
Damiani E., Capatini di V imercati, S., P araboschi, S. & Samarati, P . (2000) Securing
XML Documents. 7th International Conference on Extending Database Technology.
Konstanz, Germany.
Ford, W., Hallam-Baker, P ., Fox, B., Dillaway, B., LaMacchia, B., Epstein, J . & Lapp, J .
(2001) XML Key Management Specification (XKMS). http:/ / www.w3.org/ TR/ 2001/
NOTE-xkms- 20010330/ .
Horrocks, I., P atel-Schneider, P . F., Boley, H., Tabet, S., Grosof, B. & Dean, M. (2004)
SWRL: A Semantic Web Rule Language Combining OWL and RuleML. http:/ /
www.daml.org/ 2003/ 11/ swrl/ .
Kudo, M. & Hada, S. (2000) XML Document Security Based on P rovisional Authorization.
7th ACM Conference on Computer and Communication Security. Athens, Greece.
McGuinness, D. L. & van Harmelen, F. (2004) OWL Web Ontology
Language. http:/ / www.w3.org/ TR/ owl-features/ .
Sandhu, R. S., Coyne, E. J ., Feinstein, H. L. & Y ouman, C. E., (1996) Role-Based Access
Con- trol Models. IEEE Computer. 29(2):38 -47.
The Rule Markup Initiative. http:/ / www.ruleml.org/ .
Q in, L. & Atluri, V . (2003) Concept-Level Access Control for the Semantic Web. 2003
ACM Workshop on XML Security. Fairfax, V A.
Q u, Y ., Z hang, X. & Li, H. (2004) OREL: An Ontology-Based Rights Expression Language.
13th World Wide Web Conference. New Y ork.
XACML Technical Committee (2005) XACML 2.0 Specification Set. http:/ /
docs.oasis- open.org/ xacml/ 2.0/ access\ _ control-xacml-2.0-core-spec-os.pdf.
Xiaopeng, W., J unzhou, L., Aibo, S. & Teng, M (2005) Semantic Access Control in Grid
Com- puting. 11th International Conference on Parallel and Distributed Systems. Fukuoka, J
apan.
Y ague, M. I. & Troya, J . M. (2002) A Semantic Approach to Access Control in Web Services.
EuroWeb 2002. The Web and the GRID: From E-Science to E-Business. Oxford.
76 Brian Shields and Owen Molloy
6
Y ague, M M. (2003) Applying the Semantic Web Layers to
Access Control. 14 th International W ork shop on D atab ase and E x pert S ystems
Applications. P rague. Czech Republic.