The need for using semantic policies in science ecosystem environments is widely recognized. It is important to adopt a broad notion of policy, encompassing not only access control policies, but also trust, quality of service, and others. In addition, all these different kinds of policies should eventually be integrated into a single coherent framework, so that (i) this policy framework can be implemented and maintained by a research data infrastructure, and (ii) the policies themselves can be harmonized and synchronized [77].
Policy Management
The interactions between the different components of a science ecosystem should be governed by formal semantic policies which enhance their authorization processes allowing to regulate access and use of data and services (data policies), and to estimate trust based on parties’ properties (trust management policies).
Policies are means to dynamically regulate the behavior of system components without changing code and without requiring the consent or cooperation of the components being governed [78]. Policies, which constrain the behavior of system components, are becoming an increasingly popular approach to dynamic adjustability of applications in academia and industry.
Policies are pervasive in distributed and networked environments, for example in web and Grid applications. They play crucial roles in enhancing security, privacy, and usability of distributed services, and indeed may determine the success (or failure) of a service. However, users will not be able to benefit from these protection mechanisms unless they understand and are able to personalize policies applied in such contexts.
Many are the benefits of policy-based approaches; they include reusability, efficiency, extensibility, context-sensitivity, verifiability, support for both simple and sophisticated components, and reasoning about component behavior. In particular, policy-based network management has been the subject of extensive research over the last decade.
Policy based Interaction [77]
Policies allow for security, privacy, authorization, obligation and etc. descriptions in a machine understandable way. More specifically, service or data providers may use security policies to control access to resources by describing the conditions a requester must fulfill (e.g. a requester to resource A must belong to institution B and prove it by means of a credential). At the same time, service or data consumers may regulate the data they are willing to disclose by protecting it with privacy policies. Given two sets of policies, an engine may check whether they are compatible, that is, whether they match. The complexity of this process varies depending on the sensitivity of policies (and the expressivity of the policies). If all policies are public at both sides, provider and requester may initially already provide the relevant policies together with the request and the evaluation process can be performed in one-step evaluation by the provider policy engine and return a final decision. Otherwise, if policies may be private, this process may consist of several
steps negotiation in which new policies and credential are disclosed at each step, therefore, advancing after each iteration towards a common agreement.
Policy Specification [77]
Multiple approaches for policy specification have been proposed that range from formal policy languages that can be processed and interpreted easily and directly by a computer, to rule-based policy notation using if-then-else format, and to the representation of policies as entries in a table consisting of multiple attributes. There are also ongoing standardization efforts toward common policy information models and frameworks.
Policy specification tools like the KAoS Policy Administrator Tool [79] and the PeerTrust Policy Editor provide an easy to use application to help policy writers. This is important because the policies will be enforced automatically and therefore errors in their specification or implementation will allow outsiders to gain inappropriate access to resources, possibly inflicting huge and costly damages. In general, the use of ontologies on policy specification reduces the burden on administrators, helps them with their maintenance and decreases the number of errors.
Policy language provides a framework for specifying both authorization policies and obligation policies. A policy in KAoS may be a positive (respectively negative) authorization, i.e., constraints that permit (respectively forbid) the execution of an action, or a positive (respectively negative) obligation, i.e., constraints that require an action to be executed. A policy is then represented as an instance of the appropriate policy type, associating values to its properties, and giving restrictions on such properties.
In Rei [80] policies are described in terms of deontic concepts: permissions, prohibitions, obligations and dispensations, equivalently to the positive/negative authorizations and positive/negative obligations of KAoS.
Rule-based languages are commonly regarded as the best approach to formalizing policies due to its flexibility, formal semantics and closeness to the way people think.
Policy Constraints. A constraint can optionally be defined as part of a policy specification to restrict the applicability of the policy. It is defined as a predicate referring to global attributes such as time (temporal constraints) or action parameters (parameter value constraints). Preconditions could define the resources which must be available for a management policy to be accomplished.
Propagation to Sub-domains. Policies apply to sets of objects within domains, but domains may contain sub-domains. To avoid having to re-specify policy for each sub-domain, policy applying to a parent domain, should propagate to member sub-domains of the parent. A sub-domain is said to
inherit, the policy applying to parent domains.
Policies can be specified in many different ways and multiple approaches have been proposed in different application domains. There are, however, some general requirements that any policy representation should satisfy regardless of its field of applicability:
Expressiveness to handle the wide range of policy requirements arising in the system being managed;
Simplicity to ease the policy definition tasks for administrators with different degrees of expertise;
Enforceability to ensure a mapping of policy specifications into implementable policies for various platforms;
Scalability to ensure adequate performance; and
Analyzability to allow reasoning about policies.
The existing policy languages differ in expressivity, kind of reasoning required, features and implementation provided, etc. However, specifying policies, getting a policy right and maintaining a large number of them is hard. Fortunately, ontologies and policy reasoning may help users and administrators on specification, conflict detection and resolution of such policies.
An ontology-based description of the policy enables the system to use concepts to describe the environments and the entities being controlled, thus simplifying their description and facilitating the analysis and the careful reasoning over them. Several capabilities can benefit by this powerful feature, such as the policy conflict detection and harmonization.
In addition, ontology-based approaches simplify the access to policy information, with the possibility of dynamically calculating relations between policies and environments, entities or other policies based on ontology relations rather than fixing them in advance.
Ontologies can also simplify the sharing of policy knowledge thus increasing the possibility for entities to negotiate policies and to agree on a common set of policies.
Policy Classification
Authorization Policy defines what activities a subject is permitted to do in terms of the operations it is authorized to perform on a target object. In general an authorization policy may be positive (permitting) or negative (prohibiting) i.e. not permitted = prohibited.
Activity Based Authorization: The simplest policies are expressed purely in terms of subject, target and activity.
State Based Authorization policies include a predicate based on object state (i.e. a value of an object attribute) in the policy specification.
Obligation policy defines what activities a subject must (or must not) do. The underlying assumption is that all subjects are well behaved, and attempt to carry out obligation policies with no freedom of choice. Obligation policies are subject based in that the subject is responsible for interpreting the policy and performing the activity specified.
Activity based Obligations: Simple obligation policies can also be expressed in terms of subject, target and activity, but may also specify an event which triggers the activity.
State Based Obligation: An obligation may also be specified in terms of a predicate on object state.
A conflict may occur between any two policies if one policy prevents the activities of another policy from being performed or if the policies interfere in some way that may result in the managed objects being put into unwanted states. As the activity of a policy can specify a set of actions, there may also be conflicts between these actions within a single policy.
Policy languages allow for advanced algorithms for conflict detection and its resolution. Conflicts may arise between policies either at specification time or runtime. A typical example of a conflict is when several policies apply to a request and one allows access while another denies it (positive vs negative authorization). Description Logic based languages may use subsumption reasoning to detect conflicts by checking if two policies are instances of conflicting types and whether the action classes, that the policies control, are not disjoint. Both KAoS and Rei handle such conflicts within their frameworks and both provide constructs for specifying priorities between policies, hence the most important ones override the less important ones.
KAoS also provides a conflict resolution technique called “policy harmonization”. If a conflict is detected the policy with lower priority is modified by refining it with the minimum degree necessary to remove the conflict.
Policy Management
The adoption of a policy based-approach for controlling a system requires an appropriate policy representation and the design and development of a policy management framework.
The scope of policy management is increasingly going beyond these traditional applications in significant ways. New challenges for policy management include:
Sources and methods protection, digital rights management, information filtering and transformation, capability-based access;
Active networks, agile computing, pervasive and mobile systems;
Organizational modeling, coalition formation, formalizing cross-organizational agreements;
Trust models, trust management, information pedigrees;
Effective human-machine interaction: interruption/notification management, presence management, adjustable autonomy, teamwork facilitation, safety; and
Intelligent retrieval of all policies relevant to some situation.
Graphical tools should be provided for editing, updating, removing, and browsing policies as well as de-conflicting newly defined policies.
Policy Enforcement [77]
Cooperative policy enforcement involves both machine-to-machine and human-machine aspects. The former is handled by negotiation mechanisms: published policies, provisional actions, hints, and other metalevel information can be interpreted by the client to identify what information is needed to access a resource and how to obtain that information.
It is recommended a cooperative policy enforcement, where negative responses are enriched with suggestions and other explanations wherever such information does not violate confidentiality. For these reasons greater user awareness and control on policies is one of our main objectives, making policies easier to understand and formulate to the common user in the following ways: (i) adopt a rule-based policy specification language, (ii) make the policy specification language more friendly, and (iii) develop advanced explanation mechanisms.
Trust Management [77]
Currently, two major approaches for managing trust exist: policy-based and reputation-based trust management. The two approaches have been developed within the context of different environments. On the one hand, policy-based trust relies on “strong security” mechanisms such as signed certificates and trusted certification authorities in order to regulate access of users to services. On the other hand, reputation-based trust relies on a “soft computational” approach to the problem of trust. In this case, trust is typically computed from local experiences together with the feedback given by other entities in the network. The reputation-based approach is more suitable for environments such as Peer-to-Peer, Semantic Web and Science Ecosystems, where the existence of certifying authorities can not always be assumed but where a large pool of individual user ratings is often available.
Another approach -very common in today’s applications- is based on forcing users to commit to contracts or copyrights by having users click an “accept” button on a pop-up window.
During the past few years, some of the most innovative ideas on security policies arose in the area of automated trust negotiation. That branch of research considers peers that are able to automatically negotiate credentials according to their own declarative, rule-based policies. Rules specify for each resource or credential request which properties should be satisfied by the subjects and objects involved. At each negotiation step, the next credential request is formulated essentially by reasoning with the policy, e.g. by inferring implications or computing abductions.
Applying Policies on Science Ecosystems
The need for using semantic policies in science ecosystem environments is widely recognized. It is important to adopt a broad notion of policy, encompassing not only access control policies, but also trust, quality of service, and others. In addition, all these different kinds of policies should eventually be integrated into a single coherent framework, so that (i) this policy framework can be implemented and maintained by a research data infrastructure, and (ii) the policies themselves can be harmonized and synchronized.
In the general view depicted above, policies may also establish that some events must be logged, that user profiles must be updated, and that when an operation fails, the user should be told how to obtain missing permissions. In other words, policies may specify actions whose execution may be interleaved with the decision process. Such policies are called provisional policies. In this context, policies act both as decision support systems and as declarative behavior specifications.