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 flexibility 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 specification 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) defines an abstract
model for security in Web Service environments. It
addresses messages confidentiality and integrity, and
provides models for exchanging various security to-
ken and defining 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 verification 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-
cific service provider. The employment of languages
for the specification 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 specification language to express Web services’
policies. It is used to define 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 defining 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 specification, 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
Copyright
c
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 specification used
in service oriented architectures for expressing poli-
cies. Within WS-Policy, a policy is defined as a col-
lection of alternatives and each alternative is a col-
lection of assertions. Assertions are XML elements
identified by qualified 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 specific 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 find 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 defined
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 define 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 defined se-
mantics, allows computers to interpret this knowledge
and possibly infer further implicit knowledge. The
Web Ontology Language (OWL) (W3C, 2009) is a
language, defined 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 define 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 flexibility and ex-
pressiveness, and allows finer 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-find-bind cycle. The novelty is
represented by the Matchmaker and the Reasoner en-
tities, along with the flows 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 specification, 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 filter 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 specification of both poli-
cies is done by extending WS-Policy. Since the speci-
fication does not impose limits on the kind of allowed
assertions, as already said, for the definition 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 defined 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
final 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
defined: a security ontology, that describes security
related concepts like protocol, algorithm, credential,
and a policy ontology that defines 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 define 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 defined 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 finite 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 (fingerprint, voice), electronic
(login, password, encrypted keys, certificates), phys-
ical (smartcard, passport, identity card). Finally, by
Objective we mean a particular security service of-
fered by the system: authentication, authorization,
confidentiality, integrity and non-repudiation. These
concepts are related to each other within the ontol-
ogy, and some properties (not shown in figure for the
sake of simplicity) have been also defined:
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 defines 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. Specifically, 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
first 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
find the capability that matches at best. In the second
step the overall match between the two policies will
be evaluated. The overall match is defined to be the
minimum among the individual match levels assigned
in the first 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 specified, 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-
ifies 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 specified 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 specified objective.
Possible Match. A possible match occurs when
the requirement is more specific than the capabil-
ity. Three cases are possible: a) the requirement
specifies a more specific 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 specified 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 specification for their properties.
Perfect, Close and No Match clearly define how
requirements and capabilities match. Should the final
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 find 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 Definition
The definition 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 first serves as a con-
tainer for the requirements and capabilities expressed
through the concepts defined within the ontology.
Requestor Policy. The requestor wants to define
the following policy in terms of security requirements
and capabilities:
Requestor security requirements
Message integrity
Requestor security capabilities
SAML protocol with X.509 certificate 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 define
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
Close
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-
fied by the HMAC algorithm.
The service requirement related to requestor au-
thentication is satisfied by the requestor capabil-
ity to use SAML with X.509 certificate for au-
thentication purposes. The resulting match level
is Close Match, because the objective of authenti-
cation is satisfied by the SAML protocol.
The service requirement of using XML-Enc for
encryption is satisfied 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 defined 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 satisfies 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 certifi-
cate
Close
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-
ification 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
specifically 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 specification 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
Defining, 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-
fication, 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 specification 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, deconfliction, 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