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.

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.

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.

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

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.

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.