DAML Logo - Link to www.DAML.org
OWL for Services (OWL-S) - Security and Privacy
OWL-S Home | OWL 1 Standard | DAML Program Home


Introduction

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.

Ontologies


Credential Ontology credential.owl

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 access.

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.

Properties and 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 standardized.

See Credential Ontology for details.


Security Mechanisms Ontology security.owl

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 serviceSecurity.owl

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 type SecurityMechanism.

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 agentSecurity.owl

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.


Privacy Ontology privacy.owl

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 cryptographic properties.
  • 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 Server Privacy Policy Examples and Client Privacy Policy Examples.


Cryptographically Annotated Information Object Ontology infObj.owl

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.


Context-Sensitive Trust: An Ontological Approach context

Generally, context information can have impact on trust-relevant 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. On the basis of our integrated context and message ontology, we will illustrate sample trust policies and discuss reasoning strategies.


Matching Algorithms

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 illustrated.
    • "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


Last Updated - $Date: 2010/02/15 02:21:35 $ ($Author: martin $)