In federated query processing, di erent datasets can be queried simultaneously. Each dataset has di erent privacy policies attached, but, which privacy policy will govern the usage of the query result? In this work we propose a mechanism, based on semantic web technologies, to compose privacy policies. The originality of our approach is that our composition rules are based on the data usage context and deduce implicit terms.
The semantic web allows to express data in a way that facilitates data sharing and data analysis. On the one hand, data owners can share their data through endpoints which process queries. Privacy policies are often attached to these data. These policies describe how to use data, what is permitted, obliged or prohibited. Nevertheless, everything is not expressed and implicit aspects should be considered about data usage taking into account contextual aspects. On the other hand, data consumers access endpoints to process data using a query engine. This latter can be a federated query engine able to process queries, orchestrating simultaneous access to multiple endpoints.
The issue we deal with in this paper is, how to compute the usage policy of combined data, result of a federated query. Challenging questions are (i) how to de ne a usage policy by composition of multiple usage policies? (ii) how to take into account usage context aspects like usage location, usage purposes but also prede ned stances of users (optimistic, pessimistic)? (iii) how to compose privacy policies that are not de ned with the same set of policy terms or how to manage a term created speci cally for a policy or for a context?
In this paper, an approach for composition of usage policies, based on semantic web technologies is proposed. Besides de ning usage policies, this solution takes into account implicit or general aspects of the data usage context during policies composition.
This paper presents a usage policy model and a motivating example in Section 2. The process to compose usage policies is presented in Section 3. Related works are analyzed in Section 6, and Section 7 concludes. 2
Nowadays people own several mobile devices or plug computers with increasing capabilities to collect and generate data. Data owners must be responsible of their personal data, this means that every one should have the capability to manage his/her own data. So, every grantor should create usage policies for his/her resources as simply as possible, and in a machine-readable format, specially if data should be shared with others. In this work, we consider the use of semantic web technologies to represent privacy policies. The particularity of our policies is the usage context. 2.1
The ontology Privacy Lookout3 (PriLoo) [
PUC describes the usage policy under di erent contextual aspects. It describes (i) implicitProperties in terms of ImplicitStatus, two values are allowed, all-but-prohibited, to prohibit all implicit terms and all-but-permits-or-obliges, to permit or to oblige implicit terms; (ii) Purposes (i.e., commercial, medical, tracking, scienti c, etc.) that are considered in the usage context because they are business activities; (iii) other properties like the grantee, the grantor, concerned resources, the valid period of time, the usage locality, etc.
LegalTerms, Operations and Purposes are terms that can be structured according to a hierarchical tree using the inheritance relationship. For instance, LegalTerm \moral rights preserve" inherits of \rights preserve", consultation purpose inherits of medical purpose).4
Several standard licenses have been de ned in PriLoo like CC-By or Beerware.5 In order to simplify licenses, PriLoo allows to de ne a license as part of a family of licenses. Thus, licenses which have common descriptions are grouped 3 http://privacy-lookout.net/ontologies/2015/06/28/pl-ontology.n3. 4 See http://privacy-lookout.net/ontologies/2015/06/28/pl-usage-terms.n3 to obtain the legal terms, operations and purposes de ned in PriLoo. 5 See http://privacy-lookout.net/ontologies/2015/06/28/pl-licenses.n3 for the list of standard licenses expressed with PriLoo. into families, for example CreativeCommons or PublicDomain. These licenses can be included in PUCs.
xsd:duration xsd:datetime rdfs:Resource foaf:Agent dbpedia:Place
pl:object pl:grantor pl:grantee
lity pl:usageLoca pl:storageLocality pl:obliges pl:prohibits pl:LegalTerm
pl:duraton pl:hasLicense pl:PUC pl:License
gin pl:bpel:end
its l:perm ibits p l:proh p pl:maxUses pl:implicitProperties pl:permits pl:prohibits pl:Operation
pl:Purpose xsd:positiveInteger pl:ImplicitStatus The grantee is a geriatrician. The licence of this policy allows the read operation. Policy 2 is de ned by Mary Thomson. PUC states that data about daily activities, contained in the le Digitalresources.n3, can be accessed for scienti c purposes by a research center (speci ed in pl:grantee ). The license of this policy is CC BY that belongs to the family CreativeCommons and the write operation is permitted.
1 :License1 a pl:License ; 2 pl:permits operation:read . 3 :PUC elder1 a pl:PUC ; 4 pl:permits purpose:scientific, purpose:medical ; 5 pl:prohibits purpose:tracking ; 6 pl:object <Resident1PersonalData.n3> ; 7 pl:hasLicense :License1 ; 8 pl:duration "P0Y0M2D"^ ^ xsd:duration ; 9 pl:maxUses "3"^ ^ xsd:integer ; 10 pl:grantee <http://www.clinicasantaclarita.com/ 11 Dr Clemente Humberto Zuniga Gil.html>, <http://serenaseniorcare.com/>, <http://www.cicese.edu.mx/> ; 12 pl:grantor <Resident1.n3> ; 13 pl:usageLocality <http://dbpedia.org/resource/Mexico>, <http://dbpedia.org/resource/USA> ; 14 pl:storageLocality <http://dbpedia.org/resource/Mexico> ; 15 pl:global-preference pl:pessimistic .
a) Policy 1 1 :License2 a pl:License ; 2 pl:memberOfTheFamily lic:CreativeCommons ; 3 pl:obliges legalTerm:by ; 4 pl:permits operation:write . 5 :PUC researchCenter1 a pl:PUC ; 6 pl:object <Digitalresources.n3> ; 7 pl:hasLicense :License2 ; 8 pl:permits purpose:scientific ; 9 pl:prohibits purpose:sales, purpose:commercial ; 10 pl:duration "P0Y0M2D"^^xsd:duration ; 11 pl:grantee <http:==www.cicese.edu.mx=> ; 12 pl:grantor <MaryThomson.n3> ; 13 pl:usageLocality <http:==dbpedia.org=resource= Mexico>; 14 pl:storageLocality <http:==dbpedia.org=resource= USA> .
in line 14 of Figure 2a), usage locality (e.g., \Mexico" in line 13 of Figure 2b), the period of time of usage, number of permitted usages (e.g., 3 uses in line 9 of Figure 2a). 2.2
Motivating example: Geriatric center use case
The scenarios considered concern daily activities of a geriatric center [
Resident
Resident Personal endpoint
Personal endpoint Personal policies
Personal data
Personal policies
Personal data
...
Manager Physician
Query for purpose Query for purpose
Federated Query
Engine PrODUCE
Priloo ontology
Query for purpose Query for purpose
Resident Personal endpoint Personal policies
Personal data Scientist
Caregiver
Every two weeks a physician visits the geriatric center to check residents. She searches for the relevant data of each consulted resident, so she uses the information system to get the data. The relevant information is related with vitals signs (temperature, blood pressure, pulse, weight, etc.), meals, medicaments, but also, anomalies or comments from caregivers. In this occasion a physician requires data about blood pressure of all older adults who have hypertension.
In this scenario three policies from di erent residents are considered: Policy 1 (Figure 2), Policy 3 and Policy 4 (Figure 4). The physician needs to obtain the older adults having blood pressure > 120, which is considered as an indicator of 1 :License3 a pl:License ; 2 pl:permits operation:read, operation:distribute . 3 :PUC elder2 a pl:PUC ; 4 pl:permits purpose:medical ; 5 pl:prohibits purpose:commercial, purpose:scientific ; 6 pl:object <Resident2PersonalData.n3> ; 7 pl:hasLicense :License3 ; 8 pl:duration "P0Y0M2D"^ ^ xsd:duration ; 9 pl:maxUses "3"^ ^ xsd:integer ; 10 pl:global-preference pl:pessimistic ; 11 pl:grantee <http://serenaseniorcare.com/> ; 12 pl:grantor <Resident2.n3> ; 13 pl:usageLocality <http://dbpedia.org/resource/Mexico> ; 14 pl:storageLocality <http://dbpedia.org/resource/Mexico> .
a) Policy 3 1 :License4 a pl:License ; 2 pl:permits operation:sharing, operation:publishing, operation:distribute, operation:read ; 3 pl:obliges tlegalTerm:by . hypertension. The purpose of the physician's query is medical which is included in the query.
The geriatric center collaborates with other institutions for scienti c research purposes. Scientists investigate about speci c topics related with the caring process. This time a scientist performs an evaluation of a group of elders taking a particular drug. For this, she queries regularly the blood pressure of the group and collects related data of every older adult of the group.
For this scenario, three policies from di erent residents are also considered: License1, License4 and License5. Now, the purpose of this query is scienti c.
In both scenarios, users want to query data about older adults. Each resident has his/her own personal policy and the users their speci c query's purposes. So the need to merge every aspect of concerned policies emerged. The composition process is presented in next section. 3
The proposed composition process, generates a policy from a set of policies, see Figure 5. Firstly, input policies are extended with terms used by the PUC and the license. Then implicit terms are added according to context rules or explicit default terms. Secondly, basic composition rules are applied. Finally, inconsistencies are identi ed and solved. When the composition is not possible a FALSE answer is returned. The rationale of every stage is presented next, and illustrated, step by step, with scenarios from previous section.
In this stage, the policies are analyzed and, if necessary, all additional terms of the ontology (which are concerned by the policy) are incorporated. This rulebased process, takes into account not only terms existing at the PUC de nition but also all terms existing at the composition time (perhaps terms existing in another policy). Consequently, rules that exploit relationships with data-usage context and, sometimes, that de ne implicit terms management are proposed to complete policies. Table 1 presents examples of rules (written in Jena6) used in this stage. Three sets of rules were de ned: 1. \business rules" depend on licenses (Table 1a). For instance, these rules are used to add a purpose to a PUC or to add a legal term, associated to a given purpose, to a license. 6 Java API for RDF in https://jena.apache.org/. 2. \propagation rules" take into account inheritance of terms according to a property (Table 1b). For instance, when a term inherits from another term and the last one is permitted, then the rst one is permitted too (unless the PUC prohibits it). 3. \implicit management rules" manage implicit terms (Table 1c). If a term is not speci ed in a PUC, the propagation rules (explained before) do not conclude and the property to manage them (pl:implicitProperties ) does not exist, then, implicit management rules deduce, from the context (purposes, licenses, etc.), if unspeci ed terms are permitted, obliged or prohibited.
The input policies are pre-processed and all of them allow the medical purpose which is the main query's purpose of the physician. The expanded policies include terms added based on the medical purpose after applying the business rules. For instance, in the extended Policy 3, shown in Figure 6a, consultation and tracking purposes are added because they inherit from the medical purpose. Moreover, due to the medical purpose and after applying the implicit management rules (all-but-prohibited because in medical context all data is very important and must be treated as con dential), all not explicitly speci ed terms are added as prohibits, as well as prohibited purposes in the PUC.
One objective pursued by scientists is to publish their research results. Therefore, as a part of the context the publishing purpose inside the permits model is included in all the policies containing the scienti c purpose. These not explicitly speci ed terms are included in the pre-processing stage, the property all-butpermit-oblige is used to perform this action. This property also allows to include all not prohibited terms as obligations inside the obliges model shown in Policy 5 (Figure 6b).
In this stage, the terms of all models (permits, prohibits and obliges ) are analyzed. The operators shown in Table 2 are applied depending on the model: AND operator for permissions and OR operator for prohibitions and obligations. AND operator includes terms that appear in all the policies inside the permits model. In the prohibits and obliges models, the OR operator includes all the terms that appear in at least one policy. 7 1 :License3 a pl:License ; 2 pl:permits operation:distribute , operation:read ; 3 pl:prohibits term:rightsPreserve , term:by , term:rename , operation:publishing , term:history , term:origin , operation:unlimitedDisclosure , term:PublicDomainPreserve , term:waiver , term:using , term:fairDealing , term:holdLiable , term:lesserCopyLeft , operation:sharing , term:limitedCommercial , term:moralRightsPreserve , term:copyrightNotice , term:derivative , operation:copy , term:warranty , operation:write , term:freeSourceCode , term:otherRightsPreserve , term:sa , term:notice , term:constraintDerivative . 1 :License5 a pl:License ; 2 pl:obliges term:fairDealing , term:constraintDerivative , term:waiver , term:otherRightsPreserve , term:copyrightNotice , term:warranty , term:history , term:sa , term:notice , term:holdLiable , term:lesserCopyLeft , term:by , term:origin , term:PublicDomainPreserve , term:moralRightsPreserve , term:limitedCommercial , term:freeSourceCode , term:rightsPreserve ; 3 pl:permits operation:read , term:sharing , operation:rename , operation:distribute , operation:using , operation:unlimitedDisclosure , operation:derivative , operation:copy , operation:write , operation:publishing . 4 :PUC elder2 a pl:PUC ; 5 pl:begin "2014-02-03T00:00:00.000+01:00" ; 6 pl:duration "P0Y0M2D"^ ^ xsd:duration ; 7 pl:getPurposeFrom :License5 ; 8 pl:global-preference pl:optimistic ; 9 pl:grantee <http://serenaseniorcare.com/> ; 10 pl:grantor <Resident2.n3> ; 11 pl:hasLicense :License3 ; 12 pl:implicitProperties pl:all-but-permitted-or-obliged ; 13 pl:object ; 14 pl:permits purpose:management , purpose:scientific , purpose:tracking , purpose:privateUse , term:care , term:wellbeing ; 15 pl:prohibits purpose:sales , purpose:commercial , purpose:medical , purpose:gift , purpose:consultation ; 16 pl:storageLocality <http://dbpedia.org/resource/Mexico> ; 17 pl:usageLocality <http://dbpedia.org/resource/Mexico> ; 18 pl:maxUses 3 .
Operators execution stage for Scenario 2.
In this case, the permits purposes are scienti c and distribute. The latter as a result of the policy expansion in the pre-processing stage. The purpose medical is prohibit therefore it remains as is. The term by is obliges and all the rest of the terms added in the previous stage remain (i.e., moralRights, origin, etc.).
Generated policy in the previous stage is checked to search for inconsistencies. In this veri cation, we consider that original terms appearing in the policy have the highest priority, terms added by business rules have a medium priority, and terms added by implicit management and propagation rules have the lowest priority. Taking into account the previous priorities, next steps were applied: { if one permitted term, with the same priority, is prohibited in at least one policy, then it will not be included in the nal policy; { if two terms are not compatible then we choose one of them based on the requester purpose; { the term with the highest priority will always be included in the nal policy. Inconsistencies detection stage for Scenario 1.
The nal stage eliminates the remaining inconsistencies, i.e. the term by and constraintDerivative as obliges are the original terms. This means they have the highest priority, then they are eliminated from the prohibits model (Figure 7a). Inconsistencies detection stage for Scenario 2.
Some of the terms of the resulted policy, after the previous stage, appeared as obliges and prohibits what generates inconsistencies. Only the purpose scienti c and, terms publishing and read were as permits. For the composite policy (Figure 7b), the inconsistencies found among terms inside obliges and prohibits models are suppressed considering the priority of the terms (i.e., by, notice).
As can be seen, each purpose contributes to each policy by adding di erent terms. Also, the stance of the owner is considered, as well as the user purpose (i.e., purposes expressed in the query by the scientist - scienti c purpose - and the physician - medical purpose).
It is possible the composition gives an empty policy if the composition process does not succeed. When the composition process ends, PrODUCE sends its results to the query engine. If the process does not succeed, the result is FALSE. Otherwise, the produced policy is returned. The query engine then returns FALSE or processes the user query. If the query is possible, the composed policy is attached to the query result and the pl properties are used to specify the concerned resource (the query result as a pl:object ). 1 :resultedMedicalPolicy a pl:License ; 2 pl:obligues term:by , term:constraintDerivative ; 3 pl:permits operation:read ; 4 pl:prohibits operation:rename , term:PublicDomainPreserve , term:waiver , term:fairDealing , term:otherRightsPreserve , term:holdLiable , operation:using , term:copyrightNotice , term:warranty , operation:distribute , operation:derivative , term:sa , term:rightsPreserve , operation:copy , term:lesserCopyLeft , operation:sharing , term:by , term:unlimitedDisclosure , term:limitedCommercial , term:history , operation:write , operation:publishing , laterm:moralRightsPreserve , term:freeSourceCode , term:origin , term:notice . 5 :PUC scenario1 a pl:PUC ; 6 pl:permits purpose:medical , purpose:consultation ; 7 pl:prohibits purpose:care , purpose:tracking , purpose:management , purpose:sales , purpose:privateUse , purpose:commercial , purpose:gift , purpose:scientific , purpose:wellbeing . 8 pl:duration "P0Y0M2D"^ ^ xsd:duration ; 9 pl:grantee <http://serenaseniorcare.com/> ; 10 pl:grantor <Residen1.n3>, <Residen2.n3>, <Residen3.n3> ; 11 pl:hasLicense resultedMedicalPolicy ; 12 pl:object <CompositePersonalData.n3> ; 13 pl:storageLocality <http://dbpedia.org/resource/Mexico> ; 14 pl:usageLocality <http://dbpedia.org/resource/Mexico> ; 15 pl:maxUses 3 .
a) Scenario 1 1 :resultedScientificPolicy a pl:License ; 2 pl:obliges term:moralRightsPreserve , term:by , term:notice , term:lesserCopyLeft , term:holdLiable , term:fairDealing , term:origin , term:rightsPreserve , term:PublicDomainPreserve , term:warranty , term:copyrightNotice , term:waiver , term:sa , term:constraintDerivative , term:otherRightsPreserve , term:history , term:freeSourceCode , term:limitedCommercial ; 3 pl:permits operation:publishing , operation:read ; 4 pl:prohibits operation:rename , term:PublicDomainPreserve , term:waiver , term:fairDealing , term:otherRightsPreserve , term:holdLiable , operation:using , term:copyrightNotice , term:warranty , operation:distribute , operation:derivative , term:sa , term:rightsPreserve , operation:copy , term:lesserCopyLeft , operation:sharing , term:by , term:unlimitedDisclosure , term:limitedCommercial , term:history , operation:write , term:moralRightsPreserve , term:freeSourceCode , term:origin , term:notice . 5 :PUC scenario2 a pl:PUC ; 6 pl:permits purpose:scientific ; 7 pl:prohibits purpose:consultation , purpose:care , purpose:tracking , purpose:management , purpose:sales , purpose:privateUse , purpose:commercial , purpose:gift , purpose:medical , purpose:wellbeing . 8 pl:duration "P0Y0M2D"^ ^ xsd:duration ; 9 pl:grantee <http://cicese.edu.mx/> ; 10 pl:grantor <Residen1.n3>, <Residen2.n3>, <Residen3.n3> ; 11 pl:hasLicense resultedScientificPolicy ; 12 pl:object <CompositePersonalData.n3> ; 13 pl:storageLocality <http://dbpedia.org/resource/Mexico> ; 14 pl:usageLocality <http://dbpedia.org/resource/Mexico> ; 15 pl:maxUses 3 .
Recently, some works have focused on licenses composition in di erent contexts.
[
Contex Policies representation Models Terms Composition rules Unspeci ed terms Data-usage context
Gangadharan,
et al.[
Permission, requires, constraints by scopes: Rights: fadaptation, composition, derivation, attribution, shareAlike, non-commercialg, Finantial:fperuse, paymentg
Rules case by case
No
Mesiti,
et al.[
Set of grants
by groupes: Use:fplay, print,
executeg, Manage:finstall, uninstall, move, deleteg, Transformation:freduce, enlarge, modify, diminish, enhance, adapt, embedg Yes
Villata,
et al.[
PrODUCE
Web of data Ontology-based Ontology-based
Permissions, Permits, obligations, obliges, prohibitions prohibits DReDreiipvSsarthortaiidbvruiuencWtgtioi,oonrn,k,s, opwedrriiasttetri,oibpnuusi:btflerigseh,a,d, Notice, Attribution, terms:fnotice, by,
NoSSnCohCuoaorprcmeyeALCmleoiefkdrtec,e,i,al, pphossrocieslvidsaea:l,nftiatwceibo,amlmrcea,gmen,cdteapiyrrc,uceair,la-,l, Commercial, High- wellbeing, trackingg IncomeNationUse Deontic logic-based
Ontology-based Decision based on the data-usage context
Yes Conservative decision
No The stance assumed for unspeci ed elements depends on these rules and cannot be user or context-determined.
[
From these works, only [
Table 3 compares these works based on the policies representation, the models and terms used, the approach used in the composition, the consideration of unspeci ed terms and data usage context. 5
PrODUCE, the policies composition process presented in this paper, uses basic operators and ontology-based rules that consider data usage context.
Implicit terms, based on the usage context, extend usage policies leading to additional inconsistencies during the composition process. However, most of these inconsistencies can be eliminated with contextual rules that may incorporate priorities. This approach is very exible because, new aspects of data usage context can be easily included by extending the PriLoo ontology and de ning, accordingly, the set of rules necessary for the composition.
Future works include the de nition of rules for other contextual aspects as the laws of the usage and storage locations of concerned data. Another research direction is to analyze how to construct a feedback when the policies combination is not possible and return it to the user, instead of a false result.
Acknowledgments. Authors thank to the Mexican National Council for Science and Technology (CONACYT) for partially nancing this work.