SEMANTIC ANNOTATIONS FOR SECURITY POLICY MATCHING

IN WS-POLICY

Giuseppe Di Modica and Orazio Tomarchio

Dipartimento di Ingegneria Elettrica, Elettronica e Informatica, Universit`a di Catania

Viale A. Doria 6, 95125 Catania, Italy

Keywords:

WS-policy, Policy management frameworks, Semantic annotation.

Abstract:

Service computing technology enables B2B scenarios where the provision of a service may require a collabora-

tion among several service providers across multiple independent and heterogeneous administrative domains.

In these environments, several new security and privacy challenges arise, mainly related to resource sharing

and interoperability among different providers. Policy management frameworks are a powerful mechanism to

deal with this heterogeneity, although many issues still have to be faced with. In particular, policy matching

is today carried out following a syntactical approach, which may impair the selection of suitable services on

the one hand, and the ﬂexibility of the matching process on the other one. In this work we propose a semantic

approach that, by allowing WS-Policy assertions to reference semantic concepts, provides for a better match-

ing of security requirements and capabilities. The proposed approach has been validated through a case study

that shows how a pure syntactic-based mechanism of WS-Policy would have failed in matching two actually

compatible policies.

1 INTRODUCTION

Policy-based management has been widely employed

in enterprise information systems (Phan et al., 2008)

to automate network administration tasks. Multiple

approaches for policy speciﬁcation have been pro-

posed, ranging from formal policy languages to rule-

based policy notation. Within the last few years pol-

icy management has extended its original scope, go-

ing beyond traditional domains. Security policies are

currently used in heterogeneous service oriented ar-

chitectures (SOA) to address the problem of inter-

operability among the different security systems and

mechanisms used by each service provider.

WS-Security (OASIS, 2006) deﬁnes an abstract

model for security in Web Service environments. It

addresses messages conﬁdentiality and integrity, and

provides models for exchanging various security to-

ken and deﬁning access control mechanisms (Laksh-

minarayanan, 2010). But, if with respect to the mes-

sage security there are several well-established tech-

niques and mechanisms, the discovery and compati-

bility of security requirements among “interoperable

services” still lacks of an established methodology.

Ensuring security in the scenarios that may arise calls

for a dynamic veriﬁcation of compatibility between

the requestor’s security requirements and the service

provider’s security capabilities.

In this scenario, security policies allow to abstract

from the low-level security mechanisms of the spe-

ciﬁc service provider. The employment of languages

for the speciﬁcation of security policies will also en-

able, on the one hand, the providers to expose the

security capabilities implemented in their administra-

tive domain and, on the other one, the users to express

their security requirements. WS-Policy (W3C, 2007)

is the speciﬁcation language to express Web services’

policies. It is used to deﬁne requirements, preferences

and capabilities of services, allowing for both simple

declarative assertions as well as more sophisticated

conditional assertions. Yet the comparison of policies

within the WS-Policy framework is done at a syntac-

tic level, thus limiting the selection of suitable Web

services.

In this work we propose to semantically charac-

terize the policy assertions, by deﬁning a common

security ontology that enables mechanisms for a se-

mantic matching of security requirement and capabil-

ities. Our approach does not propose a new semantic

policy language, like instead other authors do (Uszok

et al., 2003; Kagal et al., 2003). We leverages on the

WS-Policy speciﬁcation, allowing for a lightweight

443

Di Modica G. and Tomarchio O..

SEMANTIC ANNOTATIONS FOR SECURITY POLICY MATCHING IN WS-POLICY.

DOI: 10.5220/0003564604430449

In Proceedings of the International Conference on Security and Cryptography (MPEIS-2011), pages 443-449

ISBN: 978-989-8425-71-3

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

approach where existing syntactic policies could be

processed by our semantic-aware tools and, vicev-

ersa, semantic policies could coexist within standard

WS-Policy frameworks (though not semantically pro-

cessed).

The rest of the paper is structured as follows. Sec-

tion 2 presents background and motivation of our

work. In Section 3 we sketch the overall architecture

of the framework, and provide details on the security

ontology and the matching algorithm. In Section 4 an

example is reported to validate our approach. Section

5 discussed some related work. Finally we conclude

the work in Section 6.

2 BACKGROUND AND

MOTIVATION

The adoption of a policy based-approach for manag-

ing a system requires an appropriate language for pol-

icy representation and modeling and the design and

development of a policy management framework for

policy matching and enforcement. Policies will be in-

creasingly important to effectively realize the “Inter-

net of Service” vision, where services are mainly built

through composition of services running in different

providers and/or administrative domains (Phan et al.,

2008).

WS-Policy (W3C, 2007) is the speciﬁcation used

in service oriented architectures for expressing poli-

cies. Within WS-Policy, a policy is deﬁned as a col-

lection of alternatives and each alternative is a col-

lection of assertions. Assertions are XML elements

identiﬁed by qualiﬁed names (qnames). They spec-

ify characteristics that may be used for service selec-

tion such as requirements, capabilities or behaviors of

a Web service. Policy assertions can represent both

requirements on service requestors and the capabili-

ties of the service itself. Requirements represent a de-

mand on service requestors to follow a particular be-

havior; capabilities are the service providers promises

of behavior. Among the others non functional prop-

erties of a service, WS-Policy may be used to express

security requirements and security capabilities. For

example, the use of a speciﬁc protocol to protect mes-

sage integrity is a requirement that a service can im-

pose on requestors. On the other hand, the adoption

of a particular privacy policy when manipulating data

from a requestor is a service capability.

Policy matching in WS-Policy works on a syntac-

tic level: it offers a domain independent mechanism

to ﬁnd alternatives that are compatible to two policies.

Two alternatives are compatible if, for each assertion

in one alternative, there is a compatible assertion in

the other one. Compatibility of assertions is deﬁned

exclusively according to the equality of their qname,

without any further mechanism involving their struc-

ture and content. Our work, as it will be described in

next sections, carefully extends WS-Policy by refer-

encing concepts from a security ontology directly in

the policy assertions, so maintaining backward com-

patibility with existing policy management tools.

Ontologies deﬁne a vocabulary referring to con-

cepts of a domain, their attributes and relations

amongst them. Specifying this knowledge in a

machine-readable language with formally deﬁned se-

mantics, allows computers to interpret this knowledge

and possibly infer further implicit knowledge. The

Web Ontology Language (OWL) (W3C, 2009) is a

language, deﬁned by W3C, for specifying ontologies

with formal semantics based on description logics.

There exist several implementations of OWL infer-

ence engines, so-called OWL reasoners. OWL on-

tologies can describe individuals, relations between

individuals, classes which refer to groups of individ-

uals that have something in common, and relations

between classes.

As an example, in OWL we can deﬁne that class

C is a subclass of class D, denoted as C ⊑ D, which

means that every individual belonging to C also be-

longs to D. If two classes C and D mutually are sub-

classes of each other, they are called equivalent, de-

noted as C ≡ D. Other types of complex class def-

initions that are worth citing here in order to better

understand the case study presented in our paper, in-

clude the intersection, denoted as C ⊓ D, referring to

all individuals belonging to C and D, and existential

restriction, denoted as ∃R.C, referring to all individ-

uals that have an R relationship to an individual be-

longing to class C. Based on such class descriptions,

a reasoner can infer new relations between classes.

Let us consider the following class description as ex-

ample:

3DES ⊑ SymmetricAlgorithm and B ⊑

∃uses.3DES.

From this knowledge an OWL reasoner can infer the

axiom :

B ⊑ ∃uses.SymmetricAlgorithm,

because it knows that each individual belonging to B

has a uses relationship to an individual belonging to

3DES, and thus also belongs to SymmetricAlgorithm.

From this simple example, it is possible to un-

derstand how the adoption of semantic annotations

in policies provides for improved ﬂexibility and ex-

pressiveness, and allows ﬁner policy compatibility

checks.

SECRYPT 2011 - International Conference on Security and Cryptography

444

3 SYSTEM ARCHITECTURE

The logical view of the architecture, depicted in Fig-

ure 1, recalls that of classic SOA: the requestor, the

provider and the registry keep playing their original

role in the publish-ﬁnd-bind cycle. The novelty is

represented by the Matchmaker and the Reasoner en-

tities, along with the ﬂows of policy-related infor-

mation. When advertising a given service, the Ser-

vice Description information can be integrated with

a Service Policy (step 1 in the picture). According to

the WS-PolicyAttachment speciﬁcation, such a policy

can be either attached to service’s WSDL description

or added as a new document to the UDDI registry.

When a requestor queries the registry for a service,

the latter replies with a list of the service’s feature

and attached policies (steps 2-3). At this stage the

requestor may want to ﬁlter out the returned list in

order to select the service whose policy best matches

its own Requestor Policy. We point out that Service

Policy and Requestor Policy specify requirements and

capabilities of, respectively, the service requestor and

the service provider. The speciﬁcation of both poli-

cies is done by extending WS-Policy. Since the speci-

ﬁcation does not impose limits on the kind of allowed

assertions, as already said, for the deﬁnition of the

policies we have decided to adopt semantically en-

riched terms. This, of course, will enable semantic-

based procedures of policy comparisons.

The policies are then delivered to the Matchmaker

(step 4) which is in charge for the matching pro-

cess. The comparison is carried out by overlapping

the requirements deﬁned in the Service Policy onto

the capabilities expressed in the Requestor Policy, and

viceversa. Every requirement-capability pair is as-

signed a match level and, in the end, the overall match

level between the requestor and the provider is evalu-

ate. As requirements and capabilities are expressed in

a semantic form, the Matchmaker will invoke the Rea-

soner component to perform the semantic match (step

5). The outcome of the semantic match is returned

back to the Matchmaker (step 6) that will provide a

ﬁnal response to the requestor (step 7), who will then

be able to select the appropriate service and bind to it

(step 8).

3.1 Security and Policy Ontology

To support the semantic description of security re-

quirements and capabilities two ontologies have been

deﬁned: a security ontology, that describes security

related concepts like protocol, algorithm, credential,

and a policy ontology that deﬁnes the concept of the

policy and its characterization in term of requirements

and capabilities. In the following some details about

the proposed ontologies are given. We point out that

it is not among the objectives of this work to provide

an exhaustive view of all concepts that populate the

domain of security.

In the literature many have tried to deﬁne ontolo-

gies for security. The one proposed in (Garcia and

Felgar de Toledo, 2008), that makes explicit refer-

ences to the WS-Security’s nomenclature, addresses

the problem of security when messages are exchanged

among web services. In (Kim et al., 2005) the pro-

posed ontology covers most of the concepts of the se-

curity domain: despite it was deﬁned to address se-

curity aspects at a very high levels, there are some

constructs expressly designed to semantically anno-

tate web services.

The security ontology we propose, depicted in

Figure 2, draws inspiration from the solutions pro-

posed in literature. The main concepts at the base of

the security domain are Protocol, Algorithm, Creden-

tial and Objective.

A Protocol is a set of rules agreed by parties that

need to communicate to each other. In the context of

security a protocol makes use of tools, like algorithms

and credentials, in order to accomplish an objective.

An Algorithm is a procedure for solving problems that

employs a ﬁnite number of steps. In literature several

security algorithms, divided in as many categories,

havebeen proposed. We can cite, for instance, the cat-

egory of encryption and that of authentication algo-

rithms. Credentials play an important role in informa-

tion systems that require authentication. Again, there

are several categories of credentials, among which we

can cite the biometric (ﬁngerprint, voice), electronic

(login, password, encrypted keys, certiﬁcates), phys-

ical (smartcard, passport, identity card). Finally, by

Objective we mean a particular security service of-

fered by the system: authentication, authorization,

conﬁdentiality, integrity and non-repudiation. These

concepts are related to each other within the ontol-

ogy, and some properties (not shown in ﬁgure for the

sake of simplicity) have been also deﬁned:

• a security protocol makes use of one or more se-

curity algorithms (hasAlgorithm property);

• a protocol requires one or more credentials (req-

Credential property);

• a protocol supports one or more security objective

(hasObjective property).

The policy ontology just deﬁnes the concept of

policy in the context of our framework. A policy is

nothing but a list of requirements and capabilities. In

the OWL formalization, the Policy Class and the re-

lated properties hasRequirement and hasCapabilities

SEMANTIC ANNOTATIONS FOR SECURITY POLICY MATCHING IN WS-POLICY

445

Figure 1: Overall architecture.

Figure 2: Security ontology.

have been created.

3.2 Matching Algorithm

The process of making the match between two poli-

cies consists in searching a correspondence between

requirements and capabilities. Speciﬁcally, a) the re-

quirements of a service are compared to the capabil-

ities of the requestor, and b) the capabilities of the

service are compared to the requirements of the re-

questor. In order for the comparison process to have a

positive outcome, the following conditions must hold:

• the capabilities expressed in the service policy

must meet the requirements expressed in the re-

questor policy;

• the requirements expressed in the service policy

must be met by the capabilities expressed in the

requestor policy.

The matchmaking process breaks down in two

steps: 1) assigning the match level to each

requirement-capability pair and 2) evaluating the

global match level between to overall set of require-

ments and the overall set of capabilities. As for the

ﬁrst step, each requirement-capability pair can be as-

signed one out of a scale of four different match lev-

els: Perfect Match, Close Match, Possible Match and

No Match. For each requirement, the objective is to

ﬁnd the capability that matches at best. In the second

step the overall match between the two policies will

be evaluated. The overall match is deﬁned to be the

minimum among the individual match levels assigned

in the ﬁrst step for each requirement-capability pair.

In the following we detail the four levels of matching:

• Perfect Match. A perfect match occurs when

the requirement and the capability both refer to

the same concept, or to two equivalent concepts,

and if properties are also speciﬁed, their respec-

tive values are identical or equivalent.

• Close Match. A close match occurs when the

requirement is more general then the capability.

SECRYPT 2011 - International Conference on Security and Cryptography

446

Three cases are possible: a) the requirement spec-

iﬁes a more general semantic concept than the ca-

pability’s, i.e., a concept that is higher in the onto-

logical hierarchy; b) the requirement and the ca-

pability refer to the same semantic concept, but

more details are speciﬁed for the capability (using

the “property” construct); c) the requirement is

expressed in terms of security objective while the

capability is expressed in terms of security con-

cept that supports the speciﬁed objective.

• Possible Match. A possible match occurs when

the requirement is more speciﬁc than the capabil-

ity. Three cases are possible: a) the requirement

speciﬁes a more speciﬁc semantic concept than

the capability’s, i.e., lower in the ontological hier-

archy; b) the requirement and the capability refer

to the same semantic concept, but the requirement

is speciﬁed more in details (using the property

construct); c) the requirement is expressed as se-

curity concept while the capability is expressed in

term of security objective supported by that con-

cept.

• No Match. A no match occurs when the require-

ment and the capability have no chance to match.

Two cases are possible: a) the requirement and the

capability refer to semantic concepts that have no

semantic relationship; b) the requirement and the

capability refer to the same semantic concept but

have a different speciﬁcation for their properties.

Perfect, Close and No Match clearly deﬁne how

requirements and capabilities match. Should the ﬁnal

outcome be a Possible match, nothing can be actually

said about the match level of the two policies, and a

further private negotiation step among the requestor

and the service provider is needed to ﬁnd out if there

is a real chance of compatibility.

4 CASE STUDY

In this section, an example case study is presented.

The description will focus on the security policies and

their meaning, and on the evaluation of the matching

algorithm, also explaining why a standard WS-Policy

would have failed in this case.

4.1 Security Policies Deﬁnition

The deﬁnition of security policies both for the re-

questor requirements and the server capabilities es-

sentially requires the use of two tools: WS-Policy,

and the security ontology. The ﬁrst serves as a con-

tainer for the requirements and capabilities expressed

through the concepts deﬁned within the ontology.

Requestor Policy. The requestor wants to deﬁne

the following policy in terms of security requirements

and capabilities:

• Requestor security requirements

– Message integrity

• Requestor security capabilities

– SAML protocol with X.509 certiﬁcate as au-

thentication credential

– XML-Enc for message encryption

This policy is expressed in our system in the fol-

lowing way:

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/

09/policy"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:security="http://www.semanticweb.org/ontologies/

security.owl#">

<wsp:ExactlyOne>

<security:DataIntegrity rdf:ID="capability0"/>

<security:X.509Certificate rdf:ID="X.509"/>

<security:SAML rdf:ID="capability0">

<security:reqCredential rdf:resource=

"#X.509"/>

</security:SAML>

<security:XML-Enc rdf:ID="capability1"/>

</wsp:ExactlyOne>

</wsp:Policy>

Service Policy. The service providerwants to deﬁne

the following policy (expressed in terms of security

requirements and capabilities too):

• Service security requirements

– requestor authentication

– XML-Enc protocol with AES algorithm for

message encryption

• Service security capabilities

– HMAC algorithm for message integrity

This policy is expressed in our system in the fol-

lowing way:

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/

09/policy"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:security="http://www.semanticweb.org/ontologies/

security.owl#">

<wsp:ExactlyOne>

<security:Authentication rdf:ID="requirement0"/>

<security:XML-Enc rdf:ID="requirement1"/>

<security:hasEncryptionAlgorithm

rdf:resource="http://www.semanticweb.org/

SEMANTIC ANNOTATIONS FOR SECURITY POLICY MATCHING IN WS-POLICY

447

Table 1: Requestor requirements and Service capabilities

matching.

Requestor re-

quirements

Service capa-

bilities

Match

level

Message integrity HMAC al-

gorithm for

message in-

tegrity

match

ontologies/security.owl#AES"/>

</security:XMLEnc>

<security:DataIntegrity rdf:ID="capability0">

<security:hasMACAlgorithm

rdf:resource="http://www.semanticweb.org/

ontologies/security.owl#HMAC"/>

</security:DataIntegrity>

</wsp:ExactlyOne>

</wsp:Policy>

4.2 Matching Algorithm Results

The matching algorithm tries to combine the re-

questor requirements with the server capabilities (and

viceversa) by following the approach we are going to

describe:

• The requestor’s requirement of message integrity

is combined with the service’s capability to pro-

vide data integrity through the HMAC algorithm;

the resulting level of match is Close Match be-

cause the objective of message integrity is satis-

ﬁed by the HMAC algorithm.

• The service requirement related to requestor au-

thentication is satisﬁed by the requestor capabil-

ity to use SAML with X.509 certiﬁcate for au-

thentication purposes. The resulting match level

is Close Match, because the objective of authenti-

cation is satisﬁed by the SAML protocol.

• The service requirement of using XML-Enc for

encryption is satisﬁed by the requestor using

the same protocol for this purpose. The result-

ing match level is Possible Match, because both

the requirement and the capability express the

same concept, but the requirement is deﬁned with

greater detail (the service explicitly requires the

AES algorithm).

The results are summarized in tables 1 and 2;

it may be noticed that the lowest level in all pairs

formed by the three capability-requirement combina-

tions is Possible Match. The Matchmaker informs

the requestor that the service satisﬁes its security re-

quirements. As already explained in Section 3.2, in

this case the requestor should further inquiry the ser-

vice provider before invoking the service, in order

to ascertain that the policy compatibility is granted.

Table 2: Service requirements and Requestor capabilities

matching.

Service require-

ments

Requestor ca-

pabilities

Match

level

Requestor authen-

tication

SAML with

X.509 certiﬁ-

cate

match

XML-Enc with

AES algorithm

XML-Enc Possible

match

We would like to outline that, if using the standard

WS-Policy model, the above policies would not have

matched since there is no explicit knowledge 1) that

Data integrity could be supported by the HMAC al-

gorithm and 2) that requestor authentication could be

performed by SAML mechanisms.

5 RELATED WORK

Several policy languages and framework have been

developed by adopting different approaches and used

in different application domains (Tonti et al., 2003).

Among the most notably efforts in this domain it is

worth citing Ponder (Damianou et al., 2001), a declar-

ative object-oriented language that supports the spec-

iﬁcation of several types of management policies for

distributed object systems, Kaos (Uszok et al., 2003),

a policy management framework where concepts and

policies themselves are represented using OWL, and

Rei (Kagal et al., 2003), a policy framework where

OWL is extended with the expression of relations

like role-value maps, making the language more ex-

pressive than the original OWL. Kaos and Rei are

ontology based policy languages that, although not

speciﬁcally focused on the security domain, are able

to express complex security policies: policy match-

ing is also supported by the advanced reasoning ca-

pabilities these languages offer. However, all these

languages are not compatible with existing standards

for policy speciﬁcation in service oriented architec-

tures. For this reason, similarly to our approach,

several works in the literature (Sriharee et al., 2004;

Verma et al., 2005; Speiser, 2010; Zheng-qiu et al.,

2009) have been trying to enhance WS-Policy with

semantic annotations. In (Sriharee et al., 2004), WS-

Policy assertions refer to policies expressed in OWL:

however that work is not focused on policy match-

ing, but on modeling policies as a set of rules, which

have to be evaluated using an external rule-based sys-

tem, requiring reasoning beyond OWL. In (Verma

et al., 2005) policies represented in WS-Policy are

enhanced with semantics by using a combination of

OWL and SWRL based rules to capture domain con-

SECRYPT 2011 - International Conference on Security and Cryptography

448

cepts and rules. In (Speiser, 2010) a lightweight ap-

proach to specify semantic annotations in WS-Policy

is presented: it combines the syntactic matching with

the semantic matching capability provided by OWL.

6 CONCLUSIONS AND FUTURE

WORK

Deﬁning, modeling and matching security policies is

a crucial problem that needs to be faced when dealing

with services spanning multiple administrative do-

mains. The existing models inspired to syntactic ap-

proaches are not very well suited for these heteroge-

neous and dynamic scenarios. In this paper we pro-

posed to leverage on the existing WS-Policy speci-

ﬁcation, proposing a semantic extension that enable

semantic mechanisms to matchmaking security capa-

bilities and requirements. The presented approach al-

lows to go beyond the strict syntactic intersection of

policy assertions. A security ontology is proposed to

catch the relationships among the concepts of security

Objective, Protocols, Algorithms and Credentials. A

simple example has also shown the viability of the

semantic approach and the actual limits of the pure

syntactic one. Future works will be aimed to improve

the capability to express more complex policies and

to enhance the ability of inference.

ACKNOWLEDGEMENTS

The work described in this paper has been par-

tially supported by the MIUR-PRIN 2008 project

“Cloud@Home: a New Enhanced Computing

Paradigm”.

REFERENCES

Damianou, N., Dulay, N., Lupu, E., and Sloman, M. (2001).

The ponder policy speciﬁcation language. In Proceed-

ings of the International Workshop on Policies for Dis-

tributed Systems and Networks, POLICY ’01, pages

18–38, London, UK. Springer-Verlag.

Garcia, D. Z. G. a. and Felgar de Toledo, M. B. (2008).

Ontology-Based Security Policies for Supporting the

Management of Web Service Business Processes. In

2008 IEEE International Conference on Semantic

Computing, pages 331–338. Ieee.

Kagal, L., Finin, T., and Joshi, A. (2003). A policy language

for a pervasive computing environment. In Proceed-

ings of the 4th IEEE International Workshop on Poli-

cies for Distributed Systems and Networks, POLICY

’03, pages 63–, Washington, DC, USA. IEEE Com-

puter Society.

Kim, A., Luo, J., and Kang, M. (2005). Security ontol-

ogy for annotating resources. In On the Move to

Meaningful Internet Systems 2005: CoopIS, DOA,

and ODBASE, pages 1483–1499. Springer.

Lakshminarayanan, S. (2010). Interoperable security stan-

dards for web services. IT Professional, 12(5):42 –47.

OASIS (2006). Web Services Security (WS-Security). OA-

SIS Standard.

Phan, T., Han, J., Schneider, J., Ebringer, T., and Rogers,

T. (2008). A survey of policy-based management ap-

proaches for Service Oriented Systems. In Software

Engineering, 2008. ASWEC 2008. 19th Australian

Conference on, pages 392–401. IEEE.

Speiser, S. (2010). Semantic Annotations for WS-Policy.

In IEEE International Conference on Web Services

(ICWS 2010), pages 449–456. IEEE.

Sriharee, N., Senivongse, T., Verma, K., and Sheth, A.

(2004). On using ws-policy, ontology, and rule rea-

soning to discover web services. In Intelligence in

Communication Systems, number May 2004, pages

246–255. Springer.

Tonti, G., Bradshaw, J., Jeffers, R., Montanari, R., Suri, N.,

and Uszok, A. (2003). Semantic Web languages for

policy representation and reasoning: A comparison of

KAoS, Rei, and Ponder. In International Semantic

Web Conference (ISWC2003), pages 419–437, Florida

(USA). Springer.

Uszok, A., Bradshaw, J., Jeffers, R., Suri, N., Hayes, P.,

Breedy, M., Bunch, L., Johnson, M., Kulkarni, S., and

Lott, J. (2003). Kaos policy and domain services: To-

ward a description-logic approach to policy represen-

tation, deconﬂiction, and enforcement. In Proceed-

ings of the 4th IEEE International Workshop on Poli-

cies for Distributed Systems and Networks, POLICY

’03, pages 93–, Washington, DC, USA. IEEE Com-

puter Society.

Verma, K., Akkiraju, R., and Goodwin, R. (2005). Semantic

matching of Web service policies. In Semantic Web

Policy Workshop (SDWP 2005).

W3C (2007). Web services policy 1.5 - framework. W3C

Recommendation.

W3C (2009). OWL 2 Web Ontology Language. W3C Rec-

ommendation.

Zheng-qiu, H., Li-fa, W., Zheng, H., and Hai-guang, L.

(2009). Semantic Security Policy for Web Service. In

2009 IEEE International Symposium on Parallel and

Distributed Processing with Applications, pages 258–

262. Ieee.

SEMANTIC ANNOTATIONS FOR SECURITY POLICY MATCHING IN WS-POLICY

449