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
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
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.
| Credential Ontology
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
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
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
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,
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
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
whether security capababilities and requirements of SWSs and agents are
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."
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
Security Extensions Ontology for details.
Examples using the security ontologies to mark up two service profiles
are given in Service
Agent Security Extensions Ontology
Analogously to service security extensions we define
properties ``securityRequirement'' and ``securityCapability''
with range SecurityMechanism as security extensions for agents.
Security Extensions Ontology for details.
Examples for agents with security markup are given in Agents
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
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
We define an "Entity" class with two properties "hasResource" and
"hasPolicy." A policy can have multiple "Rules", as indicated by the
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
- 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
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 cryptographic properties.
- Send and Receive are subclasses of the Transmission
class. For both, Send and Receive, we defined subclasses
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.,
Ontology for details.
Examples of privacy policies for providers (e.g., a SWS) and requesters
(e.g., an agent) are given in Server
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.
Annotated Information Object Ontology for details.
Context-Sensitive Trust: An Ontological Approach
Generally, context information can have impact on
aspects of communications. Context information can characterize a
situation of any entity---be it a person, place, or object---that is
relevant to the interaction between a user and an application,
including the user and the application themselves.
basis of our integrated context and message ontology, we will
illustrate sample trust policies and discuss reasoning strategies.
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
Stanford, May 2004,
- "Authorization and Privacy for Semantic Web Services",
Lalana Kagal, Massimo Paolucci, Grit Denker, Tim Finin, Katia Sycara,
IEEE Intelligent Systems, 2004