A framework for managing data provider and data consumer semantic obligations for access control

Abstract

Norms and policies are a fundamental component of nowadays open distributed systems operating on the Internet, and a crucial application is the field of Access Control. In such context, policies have been widely used to express data consumer permissions and prohibitions to get access to certain data, whereas obligations have been modelled and applied more infrequently. In this paper, we present a unified semantic model for specifying data consumer and data provider obligations in the context of an exchange of logically formalized information between agents, inside a Multiagent System. We explain how to specify those obligations, in a formal way; we present how to enforce the data provider obligations on the data released by the agent before returning it to the data consumer; we show how to monitor the fulfilment or violation of the specified data consumer obligations; all of that in the context of a complete reasoning-based obligation framework.

Keywords

Obligation description logics reasoning access control semantic web OWL

1. Introduction

Norms are a fundamental component of nowadays open distributed systems operating on the Internet. Norms have been widely studied as a fundamental component of Normative Multiagent Systems (NorMAS), and the studies on norms mainly concern their formalization and the definition and implementation of fundamental functionalities for norms editing, storing, promulgation, monitoring, harmonization and enforcement [2], and for norms adoption and reasoning by autonomous agents [10]. In parallel, policies (which are very similar to norms) have been studied in Access Control (AC) research, where policies and frameworks have been studied and applied to the problem of regulating access to data. The more relevant AC studies, for the work described in this paper, are the ones focused on regulating the access to the Web of Data, in an expressive and fine-grained way, by using Semantic Web Technologies [1,7,9,12,26]. In this context, policies are a widespread approach for protecting users’ privacy and security on the Internet, and for allowing or enforcing agents to abide by different policies and laws [4,22].

As described by researches in deontic logic, every norm expression can be reduced to one or a combination of two or more permission, prohibition or obligation statements [33]. In an AC context, where an agent (data consumer) sends an information request to another agent (data provider), a permission can express the conditions on which the requested information is released to the data consumer effectively. Otherwise, a denial of access can be returned. A prohibition can express the conditions for which the requested information is not released to the data consumer effectively. An obligation is able to represent a set of actions that have to be executed as a consequence of the information request, both by the data provider (data provider obligations) or by the data consumer (data consumer obligations). While data consumer permissions and prohibitions have been widely studied and formalized in AC literature (e.g., [3,20]), obligations have been modelled and applied more infrequently in such context. The main goal of this paper is to present a unified model for the enforcement of the two different types of obligations that are data provider and data consumer obligations, which are usually studied separately in literature (as presented in Section 9).

The crucial aspect is that the proposed data provider obligations may be used for specifying a very expressive set of data consumer permissions and prohibitions for accessing to certain data, more expressive than the one presented in the AC literature, as, e.g. [7,9,27]. That because, by using the proposed model of data provider obligations, it is possible to specify which pieces of data must be protected on the basis of their semantic content, and also the actions that must be taken for enforcing an AC policy. The action of filtering out some data before returning them to the data consumer (as it is proposed in many AC approaches) is only one of the interesting action that is possible to perform on the data. Other interesting actions, that are possible to be expressed with the proposed model, consist in transforming the data before to return them to the data consumer, for example by applying an anonymization procedure on certain data according to specific directives (as presented in Section 7.1). For example, it is possible to express the policy that obliges the data provider to anonymize the name of the participants of an online auction, if certain conditions are satisfied before returning them to a data consumer.

We also propose a formalization of data consumer obligations in this paper, specifying how those obligations can be monitored by a dedicated module for checking whether they are fulfilled or not. For example, a data consumer obligation may impose to an agent to pay for getting access to certain data and the monitoring module would control the effectiveness of such payment (Section 7.3). Another example of a data consumer obligation may be in use in a hospital, where a nursery can get access to certain sensitive data on condition that she/he will write a report within two weeks for explaining the reasons of the request.

The actions that are specified for a data provider obligation are executed immediately, in the context of the present work, by the data provider. An obligation that cannot be violated is called regimented [14] in the MAS literature. On the other hand, given that data consumer agents are independent with respect to the proposed system, they are autonomous components; thus, it is not possible to regiment data consumer obligations usually. In such a case, according to NorMAS literature, checking whether data consumer obligations are fulfilled or violated, according also to time constrains, becomes fundamental. Such task in a system represents a complex matter, requesting the activation of a monitoring engine for identifying the specific conditions in the system that determine the fulfilment or violation of an activated obligation (see, e.g., [17]). Furthermore, in the case in which it is allowed by the context, additional modules can be activated in order to enforce one or more agents to perform some actions, as it can be requested by an obligation.

Furthermore, we present a declarative model of obligations in this paper, inspired to the model presented in [13], in which formal axioms regarding the semantic content of the accessed data are used for regulating access to data formalized as a collection of logical statements. That with the advantage of being able to use reasoning techniques for enforcing the obligations. The fact of taking into account the semantic content of the accessed data is an important difference between the approach proposed in this paper and the approach followed by important standards in the field of Access Control, as XACML,1

¹
OASIS eXtensible Access Control Markup Language (XACML) – https://www.oasis-open.org/committees/xacml/.

W3C ACLs2

W3C ACL System – https://www.w3.org/2001/04/20-ACLs/.

or user permissions specified in the context of the SIOC project;3

SIOC Project – http://sioc-project.org/.

or in the field of license formal specification, like ODRL.4

⁴

https://www.w3.org/ns/odrl/2/ODRL21

Fig. 1.

Reasoning-based obligation framework – components and data request workflow.

The choice of using formal declarative languages (like logics languages) for expressing obligations, instead of using ad-hoc policies, implemented with routines, has the main advantage of making possible to represent the norms as data, instead of coding them into the software. That makes it possible to add, remove, or change the norms both when the system is off line, and at run-time, without the need to reprogram some components of the system or the software agents that use the system. The study of the techniques that may enable data consumer agents to reason automatically on declarative access control policies, and plan their actions consequently, is a very interesting field of research, but it is out of the scope of this paper.

Summarizing, the presented model and framework can be considered an advance of the actual state of the art for the subsequent reasons:

As far as we know, this is the first attempt to describe a model for formalizing and enforcing axiomatic obligations in the context of Access Control, where the information exchanged between agents is in the form of logical statements. Moreover, the axiomatic expression of the obligations is evaluated on the semantic content of the data itself, with the use of automatic reasoning techniques.

Both data provider and data consumer obligations are defined within a unified model, even if they are enforced in different manners, as it is requested by the system.

The model for defining and enforcing obligations can be implemented using available, standard technologies. In particular, we present an approach using semantic web languages and technologies (Section 6).

The paper proceeds as follows: we define the general framework for specifying, managing, and enforcing semantic obligations in Section 2. We describe the workflow followed by a data request in Section 3. Our obligations expression is formally introduced in Section 4; distinguishing, in particular, between data provider and data consumer obligations, and explaining their role during the whole data request workflow. We present an implementation of the model using OWL technology in Section 6. Some examples of data provider and data consumer obligations are formalized in Section 7. The results of our experiments are described in Section 8. Related work is presented in Section 9. Conclusion and future work can be found in Section 10.

2. Reasoning-based obligation framework

We identify the different modules that are needed for the data provider for editing and evaluating obligations regarding logical data, enforcing them eventually and monitoring their fulfilment during time. They are represented in Fig. 1.

The presented framework refers to the standard XACML security architecture. XACML is a standard for the specification of a security framework, defining protocols for transmitting credentials, requesting resources, defining and storing access norms; together with the definition of a general security layer, made up of different and specialised software components [23]. Such a layer deals with the tasks of allowing administrators to edit and store norms, handling conflicts between contradictory decrees, and evaluate norms.

While the obligation expression and enforcement represents the core concept of the present work, obligations are barely supported by the XACML standard. XACML defines a general syntax for obligation specification only, focusing its core functionalities on permissions and prohibitions. So, we redefined the single XACML modules for adapting them to the present needs. Some components in our framework still have a very similar purpose of their analogous XACML modules. We decided to give them different names anyway, for making it clear that we are not describing an implementation of an XACML framework. For those readers familiar with the XACML standard, we can specify that the PEP XACML module can be identified with the Enforcement Point module. The Service Interface is an analogous of the Context Handler module in XACML technology. The Norm Evaluator represents the PDP, the Norm Administrator the PAP, the User Information Interface the PIP. The Data Interface and the Monitoring Engine modules have no direct connection with an XACML module.

A detailed description of every component of the framework can be found in the subsequent sections.

2.1. Enforcement point

The Enforcement Point is the module that intercepts data consumer’s request for information and moves it to the system. As a response from the system, it receives the data requested, enriched with the information about what obligations are active on each datum, and enforces each data provider obligation before returning the data to the consumer. The active data consumer obligations are enforced, differently, by activating their monitoring by means of the Monitoring Engine and by storing information for their monitoring in the Monitoring Information Knowledge Base.

2.2. Monitoring engine

An important characteristic of autonomous agents, like data consumers, is that no assumption can be made on their internal design and, therefore, it is impossible to assume that they will always fulfil their obligations. It therefore becomes crucial to have a component in the framework for monitoring whether data consumer obligations are fulfilled or not: it is the Monitoring Engine. It is a component able to compute the state of active obligations on the basis of their content and on the basis of the actions and events that happen in the system. In order that the Monitoring Engine can use the knowledge about the state of the interaction, stored in the System State KB, for reasoning on the state of the obligations, it is necessary to provide the Monitoring Engine with a Synchronizer component, that is able to update the System State KB dynamically with the observable changes due to events or agents actions. The realization of this component may be challenging, in particular for the problem of taking into account those events that are nor observable by means of sensors or that are not directly connected to the actions that the agents perform in the framework [11]. Information about what conditions in the system have to be monitored is annotated in the Monitoring Information KB.

2.3. Service interface

The Service Interface is the module which deals with the coordination of the communications between Norm Evaluator, Enforcement Point, User Information Interface and Data Interface. In particular, it acts in order to return the output of the Norm Evaluator to the Enforcement Point as a response for a data request. As it is described in Section 2.6, the Norm Evaluator returns the information about what pieces of data are involved into the activation of an obligations. Such information is used by the Enforcement Point in order to enforce the obligations.

2.4. User information interface

The User Information Interface is the interface that retrieves the information about the requesting agent (that is conceptualized by the data provider as a generic user of the service) in the User Information KB and returns it to the Service Interface. The User Information KB is a collection of statements about what is known by the framework regarding any user that interact with the system.

2.5. Data interface

The Data Interface is the interface that retrieves the requested information in the Data KB and returns it to the Service Interface. The implementation of such component may vary according to the nature of the Data KB.

2.6. Norm evaluator

The Norm Evaluator is the component that evaluates what are the pieces of data on which each obligation must be enforced. The module is provided with a reasoning engine, in order to use inference for deducing the right conditions for the application of the obligations, starting from their formal definition.

2.7. Norm administrator

The Norm Administrator is the software component which manages the access to the stored norms (in the Norm KB). It provides the software interfaces needed by other external components for providing the users with the ability of reading, creating, editing, removing such norms. It handles concurrency in access to them, consistency, and reliability. It handles and resolves conflicts between contradictory norms, eventually.

3. Data request workflow

When a data consumer sends a request for information to a data provider, such request is processed by the framework presented in Section 2 according to the workflow that is shown in Fig. 1. We describe such workflow in detail subsequently. Each numbered item in the list refers to the corresponding numbered arrow in Fig. 1.

The data consumer sends the request for information, together with its own credentials, that is received by the Enforcement Point. The nature of the query may vary, according to different agreed protocols. It can be, e.g., an XACML request, or a SPARQL query. Anyway, we consider it as a request for information that is provided to the data consumer in the form of logical statements.

The Enforcement Point forwards the request to the Service Interface.

The Service Interface, by reading the credentials provided by the data consumer, sends a request for information about the user to the User Information Interface.

The User Information Interface sends a query to the User Information KB for retrieving the description of the requesting user, in the form of logical statements.

The description of the requesting user is returned to the User Information Interface.

The description of the requesting user is returned to the Service Interface.

The Service Interface forwards the request for information sent by the data consumer to the Data Interface.

The Data Interface translates the request as a query to the Data Knowledge Base.

Requested data is returned to the Data Interface.

Requested data is returned to the Service Interface.

Information about the requesting user, and the requested data, are now available to the Service Interface. Such information is the necessary and sufficient information for identification of which norms have to be applied to the data. Such norms have still to be retrieved. So, information about the requesting user and the requested data are sent to the Norm Evaluator, in order to apply active norms, eventually.

The Norm Evaluator sends a request to the Norm Administrator, requesting the norms that have to be applied to the data.

The Norm Administrator sends a query to the Norm KB, for retrieving the requested norms.

The norms, in the form of logical statements, are returned to the Norm Administrator.

The same norms are returned to the Norm Evaluator.

The Norm Evaluator, by reading the obtained norms, enriches the data obtained by the Service Interface with the evaluation, for each piece of data, of which norms are active and apply on such specific datum. Such enriched information is returned to the Service Interface.

The data that was obtained from the Data Interface, together with the additional information obtained from the Norm Evaluator about active norms, is returned to the Enforcement Point.

The Enforcement Point acts according to the annotated norms in order to enforce them. If editorial revisions of the response are requested, they are applied; e.g., a piece of data in the response that a norm obliges to delete, is deleted by the component. Moreover, a norm can express an obligation that have to be fulfilled by the data consumer. Such activation of a norm is sent to the Monitoring Engine and annotated in the Monitoring Information KB. The Monitoring Engine will keep the Enforcement Point aware of changes in the activated obligations status (e.g. an obligation fulfilled, or violated, see Section 7.3), in order to allow the Enforcement Point to act in different manners as a consequence of such changes. After all the active norms are or enforced on the data or notified to the Monitoring Engine for their monitoring, the final response is sent to the data consumer.

4. Obligation expression

We define an obligation, in its most general form, as a quadruple $o_{i} = ⟨ δ_{i}, α_{i}, Γ_{i}, t_{i} ⟩$ , where:

$δ_{i}$ is the debtor of the obligation, that is the agent who is in charge of fulfilling the obligation.

$α_{i}$ is activation condition of the obligation $o_{i}$ , it is a generic axiom written using the model of the data stored in the Data Knowledge Base, it is used for describing the information about what conditions have to be verified on the protected data for the obligation to become active. Logic deduction can be used for automatically evaluating those conditions. When there is at least one piece of data on which an obligation $o_{i}$ apply, according to the conditions specified in the activation condition $α_{i}$ , we say that such obligation is an active obligation.

$Γ_{i}$ is the content of the obligation $o_{i}$ . If the obligation is an obligation that should be regimented by the framework, i.e. a data provider obligation, it is a generic algorithm operating on logical statements, that is able to modify the knowledge status in the framework. Such algorithm is the one that has to be executed for every datum on which the conditions expressed in $α_{i}$ are satisfied. If the obligation is an obligation that should be monitored by the framework, i.e. a data consumer obligation, it is the axiomatic definition of the action that the debtor of the obligation is expected to perform within a given deadline. This choice has the advantage that logic deduction can be used for checking the fulfilment or violation of those type of obligations on the basis of a logical representation of the actions performed by the agents available in the System State KB. An action is described as a tuple having at least a type (for example pay) an actor, a recipient, and an object. Other properties may be obviously added when required.

$t_{i}$ is a timestamp, and it is the deadline of $o_{i}$ . If an active obligation is satisfied before the deadline, that is, the obliged action is performed within the deadline, the obligation is considered fulfilled. Otherwise, it is considered violated (see Section 7.3 for more details).

The $A = ⟨ α_{1}, α_{2}, \dots, α_{n} ⟩$ collection of all the norm activation conditions axioms represents the Norm KB in our framework, once every obligation $o_{i}$ is expressed. It is a matter, instead, of the Enforcement Point to store the other information about each obligation $(δ_{i}, Γ_{i}, t_{i})$ , in order to enforce each obligation properly.

We present a description of such enforcement mechanism in Section 5, together with two examples of obligation specification (Section 5.1 and Section 5.2).

5. Obligation enforcement

As described in the data request workflow (in Section 3) when the data is returned at last to the Enforcement Point, before its final return to the data consumer, it is required to enforce the activated obligations.

As previously described, we identify two main different types of obligation in our model: data provider obligations and data consumer obligations. Data provider obligations have as debtor the agent that releases the data, which is interested in the successful fulfilment of such obligation. Data consumer obligations have as the debtor the agent who requested the data, and it is responsible against the system in fulfilling its obligation correctly. So, the Enforcement Point has both to enforce the data provider obligations (as it is described in Section 5.1), and activate the monitoring of data consumer obligations (as it is described in Section 5.2).

5.1. Data provider obligation enforcement

A data provider obligation is an obligation where the $δ_{i}$ debtor is equal to the agent who releases the data. Such obligations are meant to be used for applying revisions on released data before returning them to the data consumer. In such a case, the $Γ_{i}$ content of the obligation is an algorithm that is defined in order to apply changes on the data itself that has to be returned to the data consumer. The $t_{i}$ deadline of a data consumer obligation is an empty field, because data provider obligations are executed on the data immediately, and the specification of a deadline is not requested in such a case.

During the enforcement of those obligation every algorithm $Γ_{i}$ is executed on the identified data for each activation condition $α_{i}$ that is active, in order to fulfil each obligation $o_{i}$ . The obtained KB is returned to the Data Consumer component, finally.

As an example, an $o_{1}$ obligation for a data provider may impose to anonymize the name of under-age patients in a hospital system before returning them, when they are requested by a data consumer. The $δ_{1}$ debtor of the obligation would be the data provider. The $α_{1}$ activation condition of the obligation would be represented by an axiom that identifies the name of any patient that is under age. The $Γ_{1}$ content of the obligation would be the set of actions that are to be executed in order to anonymize pieces of data that are identified by $α_{1}$ , before returning them to the data consumer; so, e.g., $Γ_{1}$ can specify the name of a pre-defined anonymization algorithm that can be executed on a generic string. The $t_{1}$ deadline, as explained, would be empty. Two more complex examples of data provider obligations are presented in Section 7.1 and Section 7.2.

5.2. Data consumer obligation monitoring

A data consumer obligation is an obligation where the $δ_{i}$ debtor is equal to the agent who sends the request for the data that activate the obligation. The difference between a data provider obligation and a data consumer obligation is that data consumer obligations are not regimented. Therefore, their content $Γ_{i}$ is not the algorithm that must be executed in order to modify the data to be returned, but it is an description of the action that the debtor of the obligation is obliged to perform. This description is a knowledge available in the Monitoring Information KB. Such information plus the information contained in the System State KB is the one that is necessary and sufficient for the Monitoring Engine to correctly deduce the state (fulfilled or violated) of each active obligation $o_{i}$ in the system.

As an example, an $o_{2}$ obligation for a data consumer may impose to pay € 5.00 after accessing to his/her personal medical record in a hospital system. The $δ_{2}$ debtor of the obligation would be a data consumer. The $α_{2}$ activation condition of the obligation would be represented by an axiom that identifies every personal medical record of the requesting user in the Data KB. The $Γ_{2}$ content of the obligation would be a description of the action that the data consumer have to perform, that is the payment of € 5.00. Such description is stored in the Monitoring Information KB. The Monitoring Engine has the duty to check in every instant the Monitoring Information KB and the System State KB in order to always be aware of whether such active obligation is in the state of fulfilled or violated.

6. Implementing the obligation framework using OWL 2 technology

An implementation of the presented model can be developed using the Web Ontology Language 2 (OWL 2) technology,5

⁵
OWL 2 Web Ontology Language Document Overview – http://www.w3.org/TR/owl-overview/.

for annotating and reasoning on Description Logics (DL) statements. In such an implementation, every framework knowledge base can be represented by an OWL ontology. There are different reasons for preferring OWL 2 in respect to other technologies for annotating logical statements, in particular:

DL is a decidable subset of First Order Logic (FOL).

OWL 2 is a standard since 2009, for annotating statements with DL semantics.

Free tools are available for annotating knowledge in the OWL standard (e.g., JAVA Jena6

⁶

Apache Jena – https://jena.apache.org/.

and OWL API tools7

⁷

The OWL API – http://owlapi.sourceforge.net/.

) and reasoning on the available knowledge (e.g., Pellet [31] and Hermit [29] reasoners).

By using the OWL language it is possible to reuse existing ontologies, as, e.g., the OWL Time Ontology for the representation of instant of time and interval of time, and the FOAF Ontology8

⁸

http://xmlns.com/foaf/spec/

for the representation of data consumer profiles.

The activation condition $α_{i}$ of an obligation can be defined with an OWL class axiom or using rules written with a DL rule language, as, e.g., using a SWRL9

⁹

https://www.w3.org/Submission/SWRL/

rule. The axiom or the rule is written with the objective of defining a class of individuals

C_{i}

having the characteristics of the piece of data that is required to be protected.

As previously explained, each obligation $o_{i}$ becomes active when the activation condition of the obligation has been verified. In our concrete realization using OWL technologies, this happens when there is at least one individual in the ontology that belongs to the activation condition class $C_{i}$ defined by $α_{i}$ axiom or rule. In the context of access control, we can imagine that a data consumer submits a request for a specified subset of data contained in the Data KB. The requested data is retrieved by the Data Interface, and information about the current data consumer is obtained from the User Information Interface, allowing the Service Interface to enrich the ontology with such information. Data is then passed to the Norm Evaluator, which adds the available collection of norms to the information and applies reasoning, deducing, among all the theorems, which individuals are included into the various activation condition classes $C_{i}$ . If there is at least one individual in $C_{i}$ (that is, there is something to be protected), the corresponding obligation $o_{i}$ becomes active.

The choice of formalizing the activation conditions of obligations using OWL classes has many advantages. First, in the definition of the activation condition class, it is possible to use the rich set of OWL operators available for defining classes, as, for example, the intersection of classes or properties restriction. Therefore, it is possible to exploit the reasoning capability of an OWL reasoner and deducing new knowledge from the data in the Data KB in order to verify the activation of obligations correctly. Another advantage is that the activation condition is written in an ontology, so it is possible to change it by simply using an ontology editor without the need to re-code a software.

If $o_{i}$ is a data provider obligation, it must be regimented by executing the algorithm described in its content $Γ_{i}$ .

If $o_{i}$ is a data consumer obligation, it must be monitored by the Monitoring Engine. Therefore, its content $Γ_{i}$ , consisting in one or more OWL axioms or DL rules, for describing the obliged action, must be stored in the Monitoring Information KB. In the System State KB a collection of concepts and observable facts about the system state and temporal axioms are stored by the Synchronizer component. As described in [13], time can be modelled with OWL technology importing the necessary knowledge from the OWL Time Ontology.10

¹⁰

OWL Time Ontology – http://www.w3.org/TR/owl-time.

That is done in order to represent the state of the system correctly for each instant of time and perform a dynamic monitoring of the state of interaction between different agents with respect to the specified set of obligations.

It has to be noticed that one data consumer obligation defined at design time may be activated different times by different requests posed by different users or by the same user with different deadlines. Therefore different activation of the same obligation may be stored in the Monitoring Information KB. Every active obligation may then become:

Fulfilled: the obligation is active and the action described in the content of the obligation has been performed before the specified deadline.

Violated: the obligation is active and action described in the content of the obligation has not been performed before the specified deadline.

7. Examples

We present two data provider obligations formalization and implementation examples in Section 7.1 and in Section 7.2, with a reference to the real life scenario of eBay auctions. We formalize in Section 7.3 a data consumer obligation example, explaining how it can be defined, activated and monitored using OWL technology.

7.1. First case study and data provider obligation example: eBay anonymization of bidders

The company eBay Inc. releases information about its auctions since 2011 through its API11

¹¹
eBay Developers Program – https://go.developer.ebay.com/.

to external agents, in the form of different standard structures (e.g., XML, JSON). We took as an example the case in which the same data would be released by the eBay API in the form of logical statements. Such format, in fact, was never supported by the eBay API up to the present day. So, the eBay case studies presented in this work represent ideal experiments that have been done in the past, and they have never been applied in real conditions. We described the main concepts that are involved in such context in an OWL TBox, and we collected some sample auctions in an OWL ABox. The most relevant concepts are presented in Fig. 2, together with some sample individuals.

Fig. 2.

eBay auctions ontology – example of roles. The users paulMatthews and johnAndrews are two bidders in auction1002, while the user markLondon is the owner of the same auction.

As it can be seen in Fig. 2, the role of each user in an auction is modelled as an individual itself (bidder01 is an example, in Fig. 2), as it has already been done in other ontological models (e.g., [16]). That allows to model the different interactions between the users in the auctions according to their role correctly, allowing the same user to cover different specific roles in different run of the auctions (that is in different institutional spaces).

eBay presents a policy between its data access terms that requests some information to be anonymized, before it is released, according to specific conditions:12

¹²

eBay Bidding Overview – http://pages.ebay.com/help/buy/bidding-overview.html.

To keep certain info private, we limit how bid history information is displayed. When the highest bid, reserve price, or Buy It Now price reaches or exceeds a certain level, members can’t view or search for member-specific information, such as user IDs, on the Bid History page. Though the Bid History: Details page has information on bidders, each bidder is assigned an anonymous name (x***y, for example). Only the seller can see a bidder’s user ID. Note: eBay determines when user IDs are no longer viewable based on the price or bid amount, and this varies by country.

It can be noticed that the presented policy can be modelled as a data provider obligation, according to what is presented in Section 4. Such policy is based on the role of the requesting user, as well as the content of the data requested.

According to such policy, we specify as an example, according to our model, the fact that in the case that the data consumer is not the owner of an auction, the identity of a bidder that made any offer in such an auction is anonymized.

The activation condition of obligation $o_{3}$ is defined by the following class axiom $α_{3}$ ,13

¹³

The syntax in which all DL axioms are presented in this paper is the Manchester OWL Syntax http://www.w3.org/TR/owl2-manchester-syntax/.

which defines the class

C_{3}

that in the OWL Norm KB is called ActivationCondition03.

Class: ActivationCondition03

EquivalentTo: Role and hasRoleName

value bidder and isDefinedIn some

(inverse(isDefinedIn) some

(hasRoleName value owner and

(inverse(hasRole) some

(not CurrentUser))))

where CurrentUser is a special class including the individual representing the data consumer in the ontology. Thus, the presented class axiom defines any role of any user that is a bidder of an auction whose $owner \notin CurrentUser$ as a member of the class ActivationCondition03.

We can imagine, then, a request for information of the user paulMatthews (data consumer) to eBay (data provider), about the data of some auctions. The requested data is retrieved by the Data Interface, and information about paulMatthews is obtained from the User Information Interface, allowing the Service Interface to enrich the ontology with such information, and to add the axiom CurrentUser = {paulMatthews} to the ontology. Data is then passed to the Norm Evaluator, which adds the available collection of norms to the information and applies reasoning, deducing, among all the theorems, which individuals are included into the ActivationCondition03 class.

Fig. 3.

Embargo law conceptual representation, in the context of eBay auctions.

The so-enriched ontology, then, can be returned to the Enforcement Point that can apply a set of defined actions $Γ_{3}$ to each individual of ActivationCondition03. Referring to the ontology shown in Fig. 2, in order to anonymize a user, we propose the subsequent procedure. A new individual is created that is an anonymized version of such user. Then, the original hasRole relation between the user and its bidder role in an auction is removed, and a new hasRole relation is created between the generated anonymous individual and the bidder role. So, $Γ_{3}$ can be described as the collection of actions that, for every role $ρ_{j} \in ActivationCondition 03$ :

Generates a new user in the ontology, that represents an anonymized version of the user $ι_{k}$ : $hasRole (ι_{k}, ρ_{j})$ , if and only if that has not been done before.

Deletes the hasRole property between $ι_{k}$ and $ρ_{j}$ .

Connects the anonymous user to $ρ_{j}$ with the hasRole property.

Deletes $ι_{k}$ , if and only if it has no more hasRole connections in the ontology.

7.2. Second data provider obligation example: Releasing data that are compliant with embargo laws

In the eBay online auctions context, items are sold in an international environment in which a generic item is sold to a winning user that is not in the same country as the opened auction necessarily; e.g., an item that is located in the United Kingdom can be purchased by a user that lives in South Africa. In different countries in the world, there are specific laws forbidding citizens to sell specific types of items to specific countries. eBay asks its user to be compliant with such specific policies, as stated in its rules specifically:14

¹⁴
http://pages.ebay.com/help/policies/embargo.html

Various US agencies have restrictions in place that regulate or ban all trade with certain countries. eBay doesn’t allow the sale of embargoed or restricted items from these countries. Federal agencies also ban or regulate trade between people in the US and certain organizations, businesses, and individuals. eBay doesn’t allow those organizations, businesses, or individuals to use our website. Under US law, buying or selling certain items made in restricted countries may not be lawful, depending on the nature of the item, when it was manufactured, and when it left that specific country. Sellers willing to ship internationally, as well as sellers of items made outside the US, should regularly review current information about which countries may be affected by sanctions enforced by the Office of Foreign Assets Control (OFAC), a division of the US Department of the Treasury. For more information about laws governing such trade, please see additional information below. Make sure you follow these guidelines. If you don’t, you may be subject to a range of actions, including limits of your buying and selling privileges and suspension of your account.

Anyway, there is to say that, up to writing time, there is no infrastructure in the eBay context for checking whether such policies are followed of violated by users automatically. With our model, we can propose the specification of a single data provider obligation for an ontological representation of the eBay context, whose specification is sufficient in order to remove the information about forbidden auctions to users living in specific countries, before returning every information requested by a data consumer. There is to notice that a user under an embargo law is unable to generate offers for a specific auction, but she/he is allowed to know about the existence and the features of such auction anyway. In our example, differently, auctions in which a user is forbidden to generate offers, are removed from the results. Such choice has been made for generating a better user experience, hypothesizing a context in which a user is exploring auctions for buying, and nothing else. In such a front-end interface, it would be preferable if auctions for which the user is not allowed to generate offers were removed from the results.

As it can be seen in the ontology subset that is shown in Fig. 3, an embargo rule is specified for a ItemType, and it is applied from a Country to another Country. Thus, a data provider obligation $o_{4}$ can be created, where the $δ_{4}$ debtor of the obligation is the data provider, and the activation condition $α_{4}$ is a SWRL rule that is defined in order to put into the class ActivationCondition04 every auction that the requesting user (that is modelled, again, as the only member of the class CurrentUser) is not allowed to buy, according to the different embargo laws defined into the ontology. We use a SWRL rule as the activation condition of the norm in the present example because the definition of an OWL class axiom is impossible for our current purposes. That because specification of double paths between the same identities is requested, and identifying such paths is not possible using an OWL class axiom, as explained by Hitzler et al. [18].

So, we define the activation condition $α_{4}$ as the subsequent SWRL rule, which is used for defining the class $C_{4}$ that in the OWL Norm KB is called ActivationCondition04:

EmbargoRule(?er), CurrentUser(?cu),

Auction(?a),hasItemType(?a, ?it),

hasCountry(?a, ?c1),hasCountry(?cu, ?c2),

isFromCountry(?er, ?c1),

isToCountry(?er, ?c2),

isForItemType(?er, ?it) ->

ActivationCondition04(?a)

When the enriched ontology is returned to the Enforcement Point after a request by the data consumer, the set of defined actions $Γ_{4}$ can be executed. Such set can be defined as the single action of deleting every auction that is included into the class ActivationCondition04 before to return the data to the data consumer.

7.3. Data consumer obligation example

As an example, the obligation $o_{5}$ may oblige a user who requests the data of some eBay auctions to pay € 5.00 after the response of the data provider, no later than the time of the request plus the interval interval1.

The activation condition $α_{5}$ of the obligation $o_{5}$ can be represented as the following simple class axiom used for identifying the presence of at least one auction in the content of the response, the axiom defines the class $C_{5}$ that in the OWL Norm KB is called ActivationCondition05.

Class: ActivationCondition05

EquivalentTo: Auction

We assume that, as an example, the user johnAndrews asks for the data of certain auctions at the time instant2. The requested data is retrieved by the Data Interface, and information about johnAndrews is obtained from the User Information Interface, allowing the Service Interface to enrich the ontology with such information, and to add the axiom $CurrentUser = {johnAndrews}$ to the ontology. Data is then passed to the Norm Evaluator, which adds the available collection of norms to the information and applies reasoning, deducing, among all the theorems, which individuals are included into the ActivationCondition05 class. If there is at least one individual in ActivationCondition05 class, the Monitoring Engine is informed by the Enforcement Point to starts to monitor obligation $o_{5}$ and the content axiom $Γ_{5}$ that describes the obliged action to pay € 5.00 is added to the Monitoring Information KB together with the deadline05 equivalent to instant2 + interval1.

For the present example, the content of the obligation $Γ_{5}$ can be represented by the subsequent class axiom that defines the class Content05:

Class: Content05

EquivalentTo: Pay

and hasActor value johnAndrews

and hasRecipient dataProviderSystem

and hasObject some integer[>=5]

and hasCurrency some string["euro"]

At this point, the Monitoring Engine can infer the state of obligation $o_{5}$ in the following way. If $Content 05 = \emptyset$ and deadline05 is in the past, the obligation is violated, being that the payment has still not been done, and the deadline has been reached. If $Content 05 \neq \emptyset$ and the payment time is after deadline05, the obligation is again violated, being that the payment has been done, but that did not happen within the specified deadline. If $Content 05 \neq \emptyset$ and the payment time is before deadline05, the obligation is fulfilled, being that the payment has been done within the specified deadline.

Fig. 4.

(a) Obligation enforcement time (min) as a function of the number of individuals in the request response, for 50 and 75 obligations. (b) Obligation enforcement time (s) as a function of the number of obligations, with 250 individuals in the request response.

After the evaluation of the state of the obligation by the Monitoring Engine, the Enforcement Point can then apply specific actions in the system eventually, as enforcing specific actions or apply penalties for certain agents, as described, e.g., by [5].

8. Experiments

We describe the performance of the enforcement of data provider obligations in this section, that is the most time critical part of the framework. That because the time required for the enforcement of data provider obligations determines the response time of the framework. We developed a prototype using JAVA, with JAVA OWL API for annotating the statements and Pellet [31] as DL reasoner. We measured the time for enforcing the obligations on the data to be returned to the data consumer by the data provider, as a function of the number of individuals in the response data (Fig. 4(a)) and the number of obligations to be applied (Fig. 4(b)). Tests were made with a PC with an Intel Core i7 2.7 GHz processor, 8 GB DD3 RAM.

The enforcement time is about 2 seconds for both 50 and 75 obligations when the number of individuals in the response data is 100. The enforcement time is about 3 seconds for both 50 and 75 obligations when the number of individuals in the response data is 250. However, the function increases exponentially and, for example, the enforcement time is 6 minutes and 38 seconds for 1500 individuals and 50 obligations. That suggests that the higher is the expected value for the number of individuals in the response, the more such reasoning-based framework results an inconvenient choice for enforcing obligations.

The graph in Fig. 4(b) shows that the number of obligations seems not to influence the enforcement time as much significantly. For example, enforcement time for 5 obligations and 250 individuals is 2.01 s, while enforcement time for 20 obligations and 250 individuals is 2.8 s. A 4x number of obligations raised the enforcement time of 28.21%. The graph shows, however, a polynomial growth of the enforcement time in function of the number of the obligations.

In conclusion, scenarios in which usual responses contain few individuals (e.g., a query for requesting information about a single eBay auction, see Section 7.1) present a high usability for the approach with ordinary software technologies and hardware. Scalability problems coming from higher expected values of the number of individuals in the response should be tackled with better hardware solutions or optimized algorithms.

9. Related work

As clarified in the introduction, the model of obligations and the framework presented in this paper are related to two main field of research:

the studies on Access Control policies and frameworks, mainly in the field of regulating access to the Web of Data in an expressive and fine-grained way, by using Semantic Web Technologies;

the studies on the formalization and enforcement of norms in Normative Multiagent Systems, again by focusing on works where Semantic Web Technologies are used.

We think that the important advantage of combining and comparing studies on the same concepts, but belonging to two different fields of research, can help to improve the existing models and frameworks and can take to an advancement of the state of the art. In this section, we discuss works in the first field initially, and then two approaches belonging to NorMASs studies.

Bettini et al. [5] present a model for specifying and evaluating provisions and obligations in a pioneering work in the context of Access Control. It is based on the expression of Datalog Rules and reasoning for evaluating norms. They use the word “provision” to refer to the conditions that have to be met before data is released after a request. However, any expression of such type can be reduced syntactically to the form of a permission or a prohibition. We differ from the work of Bettini et al. in the fact that reasoning is applied to the data in order to infer what pieces of information are to be altered according to the application of each obligation. Also, they do not describe any monitoring engine.

Gama et al. [17] present a platform for specifying, monitoring and enforcing obligations in open systems. The language for expressing obligations is an arbitrary extension of the non-standard language SPL (Security Policy Language) [25]. Their monitoring engine includes the modelling of time constraints, obligation statuses and actions of enforcement. We differ from such a work in defining norms using logical statements and using reasoning for inferring the consequence of data provider obligations, and the status of each data consumer obligation.

Irwin et al. [19] describe an abstract meta-model for the obligation management. They start from the consideration that obligations are not to be assigned blindly to agents. Instead, a system should only allow obligations to be assigned when the receiving subject has sufficient privileges to fulfil them. They continue, then, describing how to monitor and verify such conditions. Furthermore, they describe an environment in which, in the case that an obligation goes unfulfilled, it is always possible to clearly identify whose fault it is (accountability). While our meta-model presents simpler constraints, it is applied to semantic pieces of information and presents a framework and an implementation, while Irwin et al.’s work represents a much more abstract definition of a normative system.

Carminati et al. present a model of policies for expressing permissions, prohibitions, authorizations to access social network data formalized in OWL in [7]. In particular, policies are formalized as SWRL rules, that are used for deducing that a certain user is able, not able or authorized to perform a certain operation on a given resource. The approach is focused on social network data where the data consumer is represented in the protected data. The work describes access rules enforcement for simple requests that consider resources as atomic data with no interest in their content. Differently, the present work is able to manage complex and fine-grained security requirements that take into account the content of the data returned to the data consumer. Moreover, the description of the requesting user is not considered as a part of the available data in the present work, as it can be assumed for social networks, making it a different and complementary approach in such sense.

A work related with what is described by Carminati et al. [7] is presented by Masoumzadeh et al. [21]. The main focus of such work is the protection of OWL relations that are expressed in social network data, by means of their reification and by specifying access policies using SWRL rules.

Access control policies for managing access to the TBox of an OWL ontology are presented by Alamri et al. [1]. Queries are analyzed in order to classify them as concept or relation queries. Norms are defined as a pair used for connecting one role with a permission rule. We differ from such work for a more extended representation of norms (axiomatic description, in our OWL implementation), and in a focus on the modelling of obligations instead of permissions.

In [27], Sacco et al. present a framework for expressing and managing attribute-based permissions on ontological data. They introduce a Privacy Preference Ontology (PPO) for Linked Data: RDF resources, RDF statements and RDF graphs can be enriched with access control statements. The PPO allows to express queries for defining who authorized users using SPARQL ASK queries that specify which attributes or properties the user must satisfy. Such queries are executed by the Privacy Preference Manager on the FOAF profile of the requester, in order to check if a given user is authorized to access or not to specific resources or statements. Such model assumes a private-by-default policy. We differ from such approach, mainly, in presenting a model for generating norm in the context of OWL ontological data, and not the simpler RDF format. Moreover, we assume a public-by-default assumption for data.

A context-based authorization mechanism for RDF graph stores is presented in [9]. Similarly to [27], they propose to use SPARQL 1.1 ASK queries (in this case on the context of the user, instead of on its FOAF profile) for expressing access conditions. The authors propose to change the submitted SPARQL query on the basis of the policy related to the named graphs that are involved in the original SPARQL query. A difference between the approaches presented in [9,27] and the one presented in this paper is the fact that the reasoning functionalities on RDF data and SPARQL queries are limited to the ones allowed by the SPARQL 1.1 query language. Instead, the present work is able to deduce the correct authorizations by means of the DL expressivity of an OWL 2 ontology. Moreover, only authorizations may be expressed with those languages, while the focus of the present work is on the expression of obligations.

Chen et al. [8] define a model of obligations in the environment of risk-aware access control. Obligations are combined with a specific measure of how much risk is incurred by allowing or denying access to specific resources. Obligations are enforced effectively if and only if the measured risk for enforcing them is lower than a specified threshold. The approach does not foresee the description of obligations under the form of logical statements, and no use of reasoning algorithms, as it is done in the present work.

At last, we consider two approaches that allow to specify access control policies on the basis of the content of the accessed data (as it is done in the present work). They are the works presented in [24,34]. In those approaches, the term “content of the data” is referred to the non-structured textual content of data (e.g., the posts published in a social network or to the text that appears in the description of case records stored in a database). In [24], Linked Data sets are used to enhance a list of keywords semantically. Such list is provided by the owner of a specific set of social network data, and it represents the policy that is used to filter the user’s posts before returning them to the data consumer. In such a context, the definition of an obligation is represented by a vector of keywords, while we present a formal and more structured representation generated by a semantic axiomatization. In [34], NLP techniques are used for measuring the distances between a set of authorized base set of records and a requested record that does not belong to the base set. If the distance, that is the similarity, is above a given threshold the access to the requested record is granted. Access control in that work is applied to databases, while our purposes are to apply obligations to semantic data exchanged between agents.

In NorMAS research the interesting approaches, where decidable description logics, defined using OWL formalisms, have been used for the definition and enforcement of obligations, are: the KAoS Policy Services Framework [32], the OWL–POLAR Framework for Semantic Policy Representation and Reasoning [28], and the OCeAN meta-model for the specification of artificial institutions and, in particular, obligations [13,15] that has been used as source of inspiration for the approach proposed in this paper.

In particular, OWL–Polar [28] is a framework for the semantic definition and enforcement of permission, prohibition and obligation statements. While their definition of an obligation fits well in our own definition involving activation conditions and contents, they do not foresee the enforcement of data provider obligations to logical data directly for access control purposes. Furthermore, while considering the possibility to use SPARQL–DL [30] queries for checking the fulfilment of data consumer obligations using reasoning, activation conditions are translated into standard SPARQL15

¹⁵
SPARQL Query Language for RDF – http://www.w3.org/TR/rdf-sparql-query/.

queries in fact, with poor or no use of reasoning. Such approach, while improving performances, lowers the expressiveness of the whole method significantly in respect to allowing the chance to add arbitrary axioms to the state of facts, for deducing new knowledge on the basis of a larger expressivity.

KAoS [6] is another framework for the definition of permissions, prohibitions and obligations. A norm is not defined with logical axioms in such a framework, but it is modelled as an individual in an ontology (corresponding to our Norm KB). Reasoning can not be used in order to apply obligations to data directly in that way, as it is done in the present work.

10. Conclusion and future work

We presented a model for defining and enforcing data provider and data consumer obligations in a system, expressing such norms as logical statements. We explained how such model can be implemented using the standard OWL technology and DL reasoning, with some examples. We developed a framework for defining and enforcing data provider obligations, presenting the performances of such environment in enforcing obligations.

Future work can include the development of a monitoring engine for checking the status of data consumer obligations. Furthermore, usability tests can be done to measure the OWL implementation applicability to real life cases, in order to consider the possibility to introduce different approaches for the development of the different modules, in the case that usability problems are noticed. Moreover, more research have to be made in supporting scalability, considering the performances of the system in answering to data consumer requests for a high number of retrieved individuals, as presented in Section 8.

Footnotes

Acknowledgement

The work described in this paper is supported by Hasler Foundation project nr. 15014 within the COST Action IS1004 WEBDATANET.

References

Alamri,

Bertok and

J.A.

Thom, Authorization control for a semantic data repository through an inference policy engine, IEEE Trans. Dependable Secur. Comput. 10(6) (2013), 328–340. doi:10.1109/TDSC.2013.20.

Andrighetto,

Governatori,

Noriega and

L.W.N.

van der Torre, Normative Multi-Agent Systems, Dagstuhl Follow-Ups, Vol. 4, Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, 2013.

Ardagna,

De Capitani di Vimercati,

Paraboschi,

Pedrini and

Samarati, An XACML-based privacy-centered access control system, in: Proc. of the 1st ACM Workshop on Information Security Governance (WISG 2009), Chicago, Illinois, USA, 2009.

Bettini,

Jajodia,

X.S.

Wang and

Wijesekera, Provisions and obligations in policy management and security applications, in: VLDB 2002, Proceedings of 28th International Conference on Very Large Data Bases, Hong Kong, China, August 20–23, 2002, Morgan Kaufmann, 2002, pp. 502–513. doi:10.1016/B978-155860869-6/50051-2.

Bettini,

Jajodia,

X.S.

Wang and

Wijesekera, Provisions and obligations in policy management and security applications, in: VLDB, Morgan Kaufmann, 2002, pp. 502–513.

Bradshaw,

Uszok,

Breedy,

Bunch,

Eskridge,

Feltovich,

Johnson,

Lott and

Vignati, The KAoS policy services framework, in: Proceedings of the Eighth Cyber Security and Information Intelligence Research Workshop (CSIIRW 2013), Oak Ridge National Labs, Oak Ridge, TN, 2013.

Carminati,

Ferrari,

Heatherly,

Kantarcioglu and

Thuraisingham, A semantic web based framework for social network access control, in: Proceedings of the 14th ACM Symposium on Access Control Models and Technologies, SACMAT ’09, ACM, New York, NY, USA, 2009, pp. 177–186. doi:10.1145/1542207.1542237.

Chen,

Crampton,

M.J.

Kollingbaum and

T.J.

Norman, Obligations in risk-aware access control, in: Proceedings of the 2012 Tenth Annual International Conference on Privacy, Security and Trust (PST), PST ’12, IEEE Computer Society, Washington, DC, USA, 2012, pp. 145–152. doi:10.1109/PST.2012.6297931.

Costabello,

Villata and

Gandon, Context-aware access control for RDF graph stores, in: ECAI,

L.D.

Raedt,

Bessière,

Dubois,

Doherty,

Frasconi,

Heintz and

P.J.F.

Lucas, eds, Frontiers in Artificial Intelligence and Applications, Vol. 242, IOS Press, 2012, pp. 282–287.

10.

Criado,

Argente and

Botti, Rational strategies for norm compliance in the n-BDI proposal, in: Coordination, Organizations, Institutions, and Norms in Agent Systems VI,

M.D.

Vos,

Fornara,

J.V.

Pitt and

G.A.

Vouros, eds, LNCS, Vol. 6541, Springer, 2011, pp. 1–20. doi:10.1007/978-3-642-21268-0_1.

11.

Criado,

Argente,

Noriega and

V.J.

Botti, Reasoning about norms under uncertainty in dynamic environments, Int. J. Approx. Reasoning 55(9) (2014), 2049–2070. doi:10.1016/j.ijar.2014.02.004.

12.

Finin,

Joshi,

Kagal,

Niu,

Sandhu,

Winsborough and

Thuraisingham, ROWLBAC: Representing role based access control in OWL, in: Proceedings of the SACMAT, ACM, New York, NY, USA, 2008, pp. 73–82. doi:10.1145/1377836.1377849.

13.

Fornara, Specifying and monitoring obligations in open multiagent systems using semantic web technology, in: Semantic Agent Systems: Foundations and Applications, Studies in Computational Intelligence, Vol. 344, Springer-Verlag, 2011, pp. 25–46, chapter 2. doi:10.1007/978-3-642-18308-9_2.

14.

Fornara and

Colombetti, Specifying and Enforcing Norms in Artificial Institutions, Springer, Berlin, Heidelberg, 2009, pp. 1–17.

15.

Fornara and

Colombetti, Representation and monitoring of commitments and norms using OWL, AI Commun. 23(4) (2010), 341–356.

16.

Fornara and

Tampitsikas, Semantic technologies for open interaction systems, Artificial Intelligence Review 39 (2013), 63–79. doi:10.1007/s10462-012-9390-7.

17.

Gama and

Ferreira, Obligation policies: An enforcement platform, in: Sixth IEEE International Workshop on Policies for Distributed Systems and Networks, 2005, pp. 203–212.

18.

Hitzler,

Krötzsch and

Rudolph, Foundations of Semantic Web Technologies, Chapman & Hall/CRC, 2009, pp. 226–229.

19.

Irwin,

Yu and

W.H.

Winsborough, On the modeling and analysis of obligations, in: ACM Conference on Computer and Communications Security,

Juels,

R.N.

Wright and

S.D.C.

di Vimercati, eds, ACM, 2006, pp. 134–143.

20.

Kolovski,

Hendler and

Parsia, Analyzing web access control policies, in: Proceedings of the 16th International Conference on World Wide Web, WWW ’07, ACM, New York, NY, USA, 2007, pp. 677–686. doi:10.1145/1242572.1242664.

21.

Masoumzadeh and

Joshi, Ontology-based access control for social network systems, IJIPSI 1(1) (2011), 59–78. doi:10.1504/IJIPSI.2011.043731.

22.

Ni,

Bertino,

Lobo,

Brodie,

C.-M.

Karat,

Karat and

Trombeta, Privacy-aware role-based access control, ACM Trans. Inf. Syst. Secur. 13(3) (2010), 24:1–24:31. doi:10.1145/1805974.1805980.

23.

OASIS XACML Version 3.0 Specification, Data-flow model, 2013, p. 19–20, http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf.

24.

Paradesi,

Liccardi,

Kagal and

Pato, A semantic framework for content-based access controls, in: Proceedings of the 2013 International Conference on Social Computing, SOCIALCOM ’13, IEEE Computer Society, Washington, DC, USA, 2013, pp. 624–629. doi:10.1109/SocialCom.2013.94.

25.

Ribeiro,

Zúquete,

Ferreira and

Guedes, SPL: An access control language for security policies with complex constraints, in: Proceedings of the Network and Distributed System Security Symposium, 1999, pp. 89–107.

26.

Sacco and

Passant, A privacy preference ontology (PPO) for linked data, in: Proceedings of the Linked Data on the Web Workshop (LDOW), Colocated with WWW, Hyderabad, India, 2011.

27.

Sacco,

Passant and

Decker, An access control framework for the web of data, in: 2011 IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications, 2011, pp. 456–463. doi:10.1109/TrustCom.2011.59.

28.

Sensoy,

Norman,

Vasconcelos and

Sycara, OWL–POLAR: Semantic policies for agent reasoning, in: The Semantic Web – ISWC 2010,

Patel-Schneider,

Pan,

Hitzler,

Mika,

Zhang,

Pan,

Horrocks and

Glimm, eds, Lecture Notes in Computer Science, Vol. 6496, Springer, Berlin, Heidelberg, 2010, pp. 679–695. doi:10.1007/978-3-642-17746-0_43.

29.

Shearer,

Motik and

Horrocks, Hermit: A highly-efficient owl reasoner, in: OWLED,

Dolbear,

Ruttenberg and

Sattler, eds, CEUR Workshop Proceedings, Vol. 432, CEUR-WS.org, 2008.

30.

Sirin and

Parsia, SPARQL–DL: SPARQL query for OWL–DL, in: Proceedings of the Third International Workshop on OWL: Experiences and Directions (OWLED ’07),

Golbreich,

Kalyanpur and

Parsia, eds, Innsbruck, Austria, 2007.

31.

Sirin,

Parsia,

B.C.

Grau,

Kalyanpur and

Katz, Pellet: A practical OWL–DL reasoner, Web Semant 5 (2007), 51–53.

32.

Uszok and

J.M.

Bradshaw, Demonstrating selected W3C policy languages interest group use cases using the KAoS policy services framework, in: POLICY, IEEE Computer Society, 2008, pp. 233–234.

33.

Wright, Deontic logics, American Philosophical Quarterly 4(2) (1967), 136–143.

34.

Zeng,

Yang and

Luo, Content-based access control: Use data content to assist access control for large-scale content-centric databases, in: IEEE International Conference on Big Data, Big Data 2014, Washington, DC, USA, October 27–30, 2014,

J.J.

Lin,

Pei,

Hu,

Chang,

Nambiar,

Aggarwal,

Cercone,

Honavar,

Huan,

Mobasher and

Pyne, eds, IEEE, 2014, pp. 27–30. doi:10.1109/BigData.2014.7004294.

A framework for managing data provider and data consumer semantic obligations for access control

Abstract

Keywords

1. Introduction

1 OASIS eXtensible Access Control Markup Language (XACML) – https://www.oasis-open.org/committees/xacml/.

2.1. Enforcement point

2.2. Monitoring engine

2.3. Service interface

2.4. User information interface

2.5. Data interface

2.6. Norm evaluator

2.7. Norm administrator

3. Data request workflow

4. Obligation expression

5. Obligation enforcement

5.1. Data provider obligation enforcement

5.2. Data consumer obligation monitoring

6. Implementing the obligation framework using OWL 2 technology

5 OWL 2 Web Ontology Language Document Overview – http://www.w3.org/TR/owl-overview/.

7.1. First case study and data provider obligation example: eBay anonymization of bidders

11 eBay Developers Program – https://go.developer.ebay.com/.

14 http://pages.ebay.com/help/policies/embargo.html

9. Related work

15 SPARQL Query Language for RDF – http://www.w3.org/TR/rdf-sparql-query/.

Footnotes

Acknowledgement

References

¹
OASIS eXtensible Access Control Markup Language (XACML) – https://www.oasis-open.org/committees/xacml/.

⁵
OWL 2 Web Ontology Language Document Overview – http://www.w3.org/TR/owl-overview/.

¹¹
eBay Developers Program – https://go.developer.ebay.com/.

¹⁴
http://pages.ebay.com/help/policies/embargo.html

¹⁵
SPARQL Query Language for RDF – http://www.w3.org/TR/rdf-sparql-query/.