Information security and privacy play an increasingly important role in a world in which the World Wide Web
is central to business, industry, finance, education, and government. Over the last decade there has been
considerable progress in the field of security, ranging from theoretical foundations and models, over languages,
methods, and tools, to applications and security system development.
The application of successful, well-founded security practices will be vital to the success of the Semantic Web
and storage, maintenance, and processing of information needs to be performed in ways that meet security requirements
such as authentication, authorization, data integrity, and privacy among others.
We propose several security-related ontologies that will enable high-level security mark-up of Web resources, services,
and agents. Our work aims at providing a layer of abstraction on top of
the various existing security standards, such as XML Signature, WS-Security, and others. In the following we propose
several security ontologies that are designed to represent well-known security techniques in terms of their
characteristics, such as mechanisms supported, credentials, notation used, etc. Furthermore, we propose an ontology
for privacy notations. We illustrate how our ontologies can be used to provide security markup for Semantic Web Services
(SWSs) and agents, detailing security capabilities and requirements of services and agents. Moreover, we have
extended our work to handle more complex security policies than those that can be expressed with the basic
security and privacy policies. The proposed ontologies are compatible with both, OWL-S versions 1.0 and 1.1,
nevertheless where necessary, we refer to OWL-S version 1.1 in namespace declarations.
On the basis of these ontological descriptions, we have also developed algorithms to identify matching pairs of
SWSs and agents that satisfy each others requirements and policies.
The process of establishing and verifying the identity of a requesting
party in a web application, so-called authentication, is often the
basis of the decision whether access is granted or not.
Authentication is based on some token, also called credential, that
the requesting party would know or have. Credentials are
one of the various
well-known authentication techniques such as name-passphrase
login, public and private keys or certificates. Our goal is to be
able to specify access control restrictions of web pages or web
services that use authentication as a requirement for authorized
We distinguish between ``SimpleCredential'' and
``ComposedCredential''. The top-level class ``SimpleCredential''
is subclassed to ``Cookie, Login, Key,
Certificate, BioMetric'', and ``OneTimePassword.'' All subclasses are
pairwise disjoint. ``Public Key'' and ``Symmetric Key'' are disjoint
subclasses of the key class. The certificate class is specialized to
``X509Certificate'', and further to the specific class of X509
certificates in XML Signature.
We have defined some of the most commonly existing classes of composed
credentials such as ``IDCard''
and ``SmartCard''. For example, a smart card can contain data such as
keys, biometric templates or PINs for authentication. Thus, composed
credentials often contain simple credentials, as modeled in our
ontology with a property ``credential''. Various specializations of identity
cards are given. A simple credential is also a subclass of the
composed credential class. Our ontology is extensible to allow for
more credential classes or further properties.
other restrictions are defined in the ontologies as well. For example
the LoginWithPassphrase class has two datatype properties defined,
``loginName'' and ``passphrase'', both of type string.
We are using the OWL ``restriction''
concept to express that the cardinality on these properties for the
login class is constrained to one. That means each
LoginWithPassphrase-credential comes along with exactly one name and
one passphrase. For the certificate class we defined an object
property, that is a property with a OWL class as its range type. The
property ``assoc'' associates with each certificate some data (such as
issuer name, serial number, etc). In the special case of an XML
Signature certificate, the object property is restricted to be of type
``X509Data''. This class is defined to be equivalent to the X509
element of the XML Signature definition.
This way we tie our ontology into an ontology that is being
See Credential Ontology for details.
Security Mechanisms Ontology
We propose an ontology that allows to interface on a high level of
abstraction among various security standards and notations. Several
properties are defined for the top class ``SecurityMechanism''.
For example, the ontology defines an object property
``syntax'' that has the class ``Syntax'' as range, another property
``relSecNotation'' has the class ``SecurityNotation'' as its range,
and ``reqCredential'' has the credential class as range. There are
various instances for the defined classes. For example, instances of
syntax are ``ASCII, DAML+OIL, OWL, XML, MIME''; security notations are
``Authentication, Authorization, AccessControl, DataIntegrity,
Confidentiality, Privacy, ExposureControl, Anonymity, Negotiation,
Policy, KeyDistribution,'' and ``X.509'' is an instance of the
KeyFormat class. ``XML-DSIG'' is an instance of the signature class
and ``OpenPGP-Enc'' is of type ``Encryption.''
Specific protocols such as ``X-KRSS, X-KISS, Kerberos,'' or ``SOAP''
are defined as instances of the appropriate protocol subclasses that
satisfy certain restrictions.
Restriction classes are classes in
which we constrain the range of one of the object properties
``reqCredential, syntax, relSecNotation'' etc. Restriction classes are
used as ``patterns'' for certain security notations.
For example, an
``AuthenticationSubClass'' is a class that has as one of its related
security notations ``Authentication''.
Thus, if a web service
has "AuthenticationSubClass" as one of its requirement then
it means that the service requires users to authenticate.
One can define other restriction classes. For example, one can
define a class where one of the required credentials is X.509 or where
the used syntax is XML.
We used the defined subclasses to characterize protocols.
For example, XKMS is defined as a protocol that is the intersection of
various classes, including the restriction classes for authentication, key distribution, and, XML.
This means, XKMS is a protocol that requires authentication, it also is a key distribution protocols
and it uses XML as syntax.
We choose to define restriction classes to represent security requirements
because we want to make use
of the inherent features of description logic (DL),
on which OWL is based,
and the tools that are available for DL reasoning. In particular, it
enables us to use subsumption reasoning. Using this technique we can decide
whether security capababilities and requirements of SWSs and agents are identical
or whether they are in an appropriate inheritance relationship. For more details on
how to use the basic ontologies to mark up services and agents see "Agent/Service Security Extensions."
See Security Mechanism Ontology for details.
Service Security Extensions Ontology
The security ontologies ("Credential" and "Security Mechanism") can be used to annotate security properties of SWSs.
We define a SecurityMechanism to be a subclass of
ServiceParameter. Then we can declare two new properties for web
services, namely ``securityRequirement'' and ``securityCapability'' of
See Service Security Extensions Ontology for details.
Examples using the security ontologies to mark up two service profiles are given in
Service Security Examples.
Agent Security Extensions Ontology
Analogously to service security extensions we define properties ``securityRequirement'' and ``securityCapability''
with range SecurityMechanism as security extensions for agents.
See Agent Security Extensions Ontology for details.
Examples for agents with security markup are given in
Agents Security Examples.
Protecting personal and enterprise privacy is critical since SWSs allow automatic exchange of information through intelligent agents without or
very little supervision of human beings. The process of accessing and delegating private information should be strictly enforced regardless
where the information is stored. Privacy policies usually define rules or concepts for accessing and using private information.
These rules and concepts include permission or right, and obligation of using private information. For example, a company is given
permission to access the client’s private information with an obligation of not giving the information to a third party.
We propose that each agent and Web service has privacy policies attached to them that can be exchanged at the beginning of an interaction
and to check whether the agent meets the privacy set forth by the service’s authority and vice a versa.
We developed a generic, simple and easy-to-use ontology for expressing privacy policies as well as a protocol to support matching of privacy policies.
We define an "Entity" class with two properties "hasResource" and "hasPolicy." A policy can have multiple "Rules", as indicated by the "hasRule" property.
Each Rule has an "Action" (as defined by "onAction" property) and is applied to a "Resource" (as specified by the "onResource" property).
If no "onResource" property is not specified, the rule will be applied to all types of resources. The resource refers to the information that must be protected. We distinguish
three types of rules: Authorization, Capability, and Obligation.
- Authorization specifies actions that allow or prohibit others from accessing the resources.
PositiveAuthorization and NegativeAuthorization are the two subclasses of Authorization.
- Capability specifies actions that the entity itself could perform in order to meet the other entity’s privacy policies if necessary.
PositiveCapability (what an entity could do) and NegativeCapability (what an entity cannot do, due to computational restrictions) are two subclasses of Capability:
PositiveIntentCapability and NegativeIntentCapability are two subclasses of PositiveCapability that describe actions that the entity intends to perform.
- Obligation specifies actions that the entity will or will not enforce. PositiveObligation and NegativeObligation are two subclasses of Obligation.
Obligations usually concern encrypted storage of data, or signing/encryption of data during transmission. Any party that accepts or advertising the policy is responsible for the
enforcement of these obligations. NegativeObligation specifies what type of collected data must not be encrypted for storage,
or data that must not be signed or encrypted during the transmission process.
Some of the action classes are further refined into subclasses.
- Local, Third Party, and Forum are subclasses of the Disclosure action class. They describe in more detail in what way information may be disclosed.
Third Party has Affiliation and NonAffiliation subclasses. Affiliation class refers to people, companies, and organizations that have a partnership
with a specific company or organization. A NonAffiliation class refers to public entities.
- StorageEncryption and StorageDecryption are subclasses of the Storage action class. A party can require selected data to be stored with certain
- Send and Receive are subclasses of the Transmission class. For both, Send and Receive, we defined subclasses TransmitEncryption, TransmitPlainText,
and TransmitSign, so that a party can specify whether data sent or received needs to be encrypted or signed or has no requirements (e.g., plaintext).
See Privacy Ontology for details.
Examples of privacy policies for providers (e.g., a SWS) and requesters (e.g., an agent) are given in
Cryptographically Annotated Information Object Ontology
In order to capture encrypted or signed input or output data of services we define an "InfObj" class (information object) and subclasses "EncInfObj" (encrypted information object)
and "SigInfObj" (signed information object). The InfObj class will be used as a range for input and output parameters of OWL-S services.
Information objects have a "baseObject" that describes the type or structure of the information that is encoded in it. For example, the base object of an I/O parameter of class
EncInfObj can be a class such as SSN. This property allows deriving knowledge about the kind of data exchanged and can be used for reasoning purposes such as
whether a service parameter fits the requirements of a client or output/input parameter of two web services match so that the services can be sequentially combined.
Furthermore, an information object can have a property "cryptoAlgUsed" to refer to the specific cryptographic algorithm that was used for signing or encrypting the data.
See Cryptographically Annotated Information Object Ontology for details.
We have designed and implemented various matching algorithms for our ontologies.
- The following papers describe the basic credential and security mechanism ontologies and matching on those
ontologies. The first paper only introduces the ontologies, the
second paper also describes the matching algorithm for those ontologies and illustrates the algorithm
with several examples.
- "Security Annotations for DAML Web Services", Grit Denker and Lalana Kagal, Internal Report, 2003,
- "Security for DAML Web Services: Annotation and Matchmaking", Grit Denker, Lalana Kagal, Tim Finin,
Massimo Paolucci, Katia Sycara, Proceedings of the Second International Semantic Web
Conference (ISWC), San Sanibel (Florida), Oct 2003,
- The following papers desribe the extension of our security ontologies to authorization and
privacy policies for OWL-S. The policies are described in Rei. Matching algorithm for these policies are
- "Authorization and Privacy for Semantic Web Services",
Lalana Kagal, Massimo Paolucci, Naveen Srinivasan, Grit Denker, Tim Finin, Katia Sycara,
AAAI Spring Symposium,
Workshop on Semantic Web Services,
Stanford, May 2004,
- "Authorization and Privacy for Semantic Web Services",
Lalana Kagal, Massimo Paolucci, Grit Denker, Tim Finin, Katia Sycara,
IEEE Intelligent Systems, 2004