## 2 Expressing Service Security Requirements  
Any _assurance process_ consists of a set of activities aimed at increasing the users' confidence that a given service will satisfy their functional and non-functional requirements. Functional requirements are already considered in the context of dynamic Web service search and discovery, while performance assurance can be addressed via suitable Service Level Agreements (SLAs). Other non-functional properties, such as security and reliability, are usually not addressed. Therefore, there is a need for a solution that (_i_) permits to specify security requirements that a given service must satisfy [4,5], and (_ii_) uses these security requirements in the context of Web service search and discovery. There are two key aspects to the notion of _service security requirements_: (1) security requirements describe a set of security properties whose semantics are shared between the service supplier and the service user; and (2) security requirements specify the process and techniques (evidence) used to verify that these security properties hold for this service. The first building block to support an assurance process for service security is the definition of the set of security properties that are of interest. The literature defines several classes of security properties including _authenticity_, _integrity_, and _confidentiality_[5]. In a Service-Oriented Architecture (SOA), security properties may concern message-level security (_i.e._, security of data in transit) and service-level security evaluating the service implementation (_i.e._, security of data at rest). In other words, we distinguish between security properties that can be proven to hold for a given service at container-level and those that need to be certified on the real service implementation. The process of evaluating a service at container-level considers the compliance of the container with Web service security standards (e.g., WS-Security [6] and WS-SecureConversation [7]) and the correct enforcement of security policies (e.g., WS-Policy [8]) defined by the service provider, to prove that the security properties are supported by the service deployed in the container. In contrast, service-level security considers security properties that need be proven by analyzing and evaluating the real service implementation. Service-level properties complement the container-level ones by providing an overview of the service that goes beyond the service interface, and considers its implementation and the developed operations. Here, we distinguish between _abstract properties_, as for instance confidentiality and integrity, and _concrete properties_ that enhance abstract ones by adding _class attributes_[9]. Indeed, no security property is entirely specified without an adversarial model, that is, a description of what an attacker can do to compromise the property. Therefore our class attributes represent (1) the threats against the property to hold (e.g., eavesdropping or replay attack), and (2) the security functions that ensure that the property holds (e.g., the access control system) [9]. Security properties are organized in an abstraction hierarchy (cf. Section 3.2). Each node in the hierarchy is a security property of the form \(p\) = (\(\hat{p}\),\(A\)), where \(\hat{p}\) is an abstract property and \(A\) is the set of class attributes in the form \(a\) = \(v\), with \(a\) the attribute name and \(v\) its value. The first-level nodes of the hierarchy are represented by all security properties \(p\) = (\(\hat{p}\),\(-\)), namely abstract security properties with no class attributes specified. An ordering relation \(\preceq\) between properties \(p_{i}\) and \(p_{j}\) (\(p_{i}\preceq p_{j}\)) indicates that \(p_{j}\) is a specification of \(p_{i}\), if and only if \(p_{i}\cdot\hat{p}\) = \(p_{j}\cdot\hat{p}\) and for each class attribute \(a\in A\), \(p_{j}\cdot a\) dominates \(p_{i}\cdot a\).