- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Wed, 20 Jul 2022 18:16:19 +0100
- To: Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>
Hi. Some updates on my thoughts about this. Also, ODRL group and DPVCG are having a joint session at W3C TPAC. See event details: https://www.w3.org/events/meetings/845fa609-cc65-414f-8960-3fff0c4c0467 - Please let us know if you plan to join. --- Q. What do we want to express here? Ans. We want the ability to specify something is permitted to take place, prohibited to take place, required to take place, or to be avoided. Here this "something" can be an entire graph, a specific PersonalDataHandling instance, or something else. Examples: 1. "We WILL NOT share your data with third parties" Condition: Recipient is ThirdParty Rule: Prohibited 2. "We WILL keep your data within EU" Condition: StorageLocation is EU Rule: Requirement 3. "You have given us permission to process your data for Security but not for Marketing" Condition: Purpose is Enforce Security Rule: Permission Condition: Purpose is Marketing Rule: Prohibition 4. "We will try not to keep your data beyond 6 months, but definitely not beyond 2 years" Condition: StorageDuration is 6 months to 2 years Rule: Avoidance Condition: StorageDuration is more than 2 years Rule: Prohibition --- Q. Why not use ODRL? ODRL is a standardised vocabulary with a rigid semantics of how classes and properties are used, and requirements for specific combinations to occur for a valid expression. For example, Prohibition class instances MUST be expressed using prohibition property and MUST contain a 'target' property with type 'Asset'. When considering dpv:PersonalData as an odrl:Asset - this seems fine. However, when we get to expressing things such as #1 above, a ThirdParty or PersonalDataHandling instance representing the data sharing is not an 'Asset' per se, even though semantically it can be considered a 'resource'. The bigger question arises from use of ODRL, where the "policies" are a separate graph on their own. For example, for expressing #1, one would have to write a DPV graph and a separate ODRL graph expressing the condition that Third Party should not be a recipient. This is fine in itself, ODRL being a standard and interoperable and all that, but it means to express permissions, prohibitions, etc. - you MUST use ODRL. This means DPVCG must assist with the incorporation / alignment of its concepts with ODRL. --- Q. ODRL is complex, how to simplify it for someone to express stuff? That is what the original proposal was - to create a concept called `Rule` under `Context` and populate it with `Requirement`, `Prohibition`, `Permission`, `Avoidance`, and `Constraint` to give a taxonomy. For anything more expressive, clear indication to use ODRL with examples. The intention is to simplify flagging some processing operations are prohibited or mandatory or permitted. Examples could be outputs of a DPIA, a DPA consultancy, consent (permit some, prohibit some), etc. The intention is to limit the scope to this, and point to other things (i.e. ODRL) for anything more complex. --- Regards, Harsh On 01/06/2022 10:04, Harshvardhan J. Pandit wrote: > Hi. > I forgot to mention yesterday that I had also looked at LegalRulemL [1] > which specifically models "legal norms, guidelines, policies and > reasoning", including defeasibility. DPV has a lot of overlap with its > concepts such as Rights, Jurisdictions, Temporality. So that is also > another option to specify "rules" alongside/extending DPV. > > [1] > https://docs.oasis-open.org/legalruleml/legalruleml-core-spec/v1.0/os/legalruleml-core-spec-v1.0-os.html > > > Regards, > Harsh > > On 31/05/2022 18:51, Harshvardhan J. Pandit wrote: >> Hi. >> >> In a previous DPVCG meeting >> (https://www.w3.org/2021/10/13-dpvcg-minutes.html), we discussed >> whether there is interest regarding providing permissions / >> prohibitions as concepts in DPV. The rationale or motivating behind >> this was to explicitly indicate something must (not) be done. >> >> --- >> >> tldr; Below is a more detailed analysis of why I propose these >> specific concepts, what else I've looked at, and that the end result >> is based on terms as per RFC 2119 while trying to not deviate too much >> from ODRL. >> >> Rule: Parent class specifying how associated information should be >> interpreted or performed >> >> Requirement: MUST happen >> Prohibition: MUST NOT happen >> Permission: SHOULD or MAY happen, implied assumption it will, but if >> it doesn't, nothing is violated by itself >> Avoidance: SHOULD NOT or MAY NOT happen, implied assumption it will >> not, but if it does, nothing is violated by itself, i.e. this says >> preferably should not take place, if permission is interpreted as "I'm >> okay if this happens", then this is its opposite as "I'm okay if this >> doesn't happen". This is required because we don't have a NOT >> concept/operator to negate/invert other concepts. >> >> Constraint: Segue to more information or rules that restrict or >> specify conditions for above concepts >> >> --- >> >> # ODRL >> >> During the discussion, we did look at ODRL concepts (Rule -> >> Permission, Prohibition, Duty). Using these (as is) would mean >> importing the entire semantics of ODRL into DPV, something that is >> neither necessary nor desirable in all uses of DPV. In an ideal >> situation, one may choose to use DPV and ODRL together to express a >> "policy", and for which we may provide some nice alignment, but there >> are other cases where such mixing may not be needed or feasible. >> >> Which brings the proposal for how to express such concepts with two >> goals. First, we do not want to redefine the wheel here - ODRL already >> has a lot of nice structure on what concepts are relevant and how they >> are use. Whatever we end up with would be good to be as close to that >> as possible. >> >> Second, we should not delve too deep here and model the specifics of >> rules and their consequences and duties (etc.) within DPV - that's >> what ODRL is exactly intended for. We should also not be rigid in how >> rules or constraints are applied, for e.g. in ODRL only policies can >> express these, whereas for our use-cases, we may want to express these >> also on specific non-policy concepts such as legal basis (e.g. >> legitimate interest has duty to notify data subject), personal data >> (e.g. prohibition on processing of special categories with constraint >> that A.9 be used), and so on. >> >> While we may not explicitly model such conditions, DPV should enable >> their expression (in other mechanisms, including ODRL). Through this, >> there rises the possibility to create a helpful knowledge base where a >> concept can have a guideline or a requirement specified without >> turning that concept into a policy (as under ODRL). >> >> # Deontic vs Epistemic terms >> >> So the proposal is to provide a lightweight series of concepts that >> are just enough to specify something is permitted or prohibited or has >> a rule or a constraint. >> >> Top concept: Rule (Parent: dpv:Concept) with the definition "A >> principle or method or procedure". Note: The description is >> intentionally as broad as possible to accommodate any potential >> concepts that relate to rules, and to enable use its beyond ODRL's >> deontological concepts (e.g. permissions, duty) to also express >> epistemological concepts (e.g. principles, guidelines). The existing >> concept dpv:Law will be a subclass of Rule following the >> interpretation of a law as a set/system of rules. >> >> The following concepts are commonly encountered regarding data >> protection / privacy. I've tried to group them with descriptions. >> >> Deontic Concepts: >> - Permission (to permit or enable), e.g. permission to process data >> - Prohibition (to prohibit or to forbid), e.g. prohibition to not >> process data >> - note that permissions and prohibitions may not be obligations, >> merely indication or preferences as well >> - Requirement (a necessity), e.g. necessity to perform processing >> - Obligation (to compel or promise), e.g. provision of a notice >> - Duty (subclass of obligation, imposition of a requirement or >> obligation based on specific context), e.g. provision of a notice by a >> Data Controller >> - Promise (subclass of obligation, a self-proclaimed acceptance of an >> obligation), e.g. not to perform analytics or profiling >> - Agreement (subclass of obligation, acceptance of obligation between >> entities), e.g. terms and conditions >> - Law (a societal set of rules as an obligation) >> >> Epistemic Concepts: >> - Principle (a rule that expresses how something should happen) >> - Guideline (a rule that suggests what is desirable) >> - Preference (a rule that places one choice above another) >> - Norm (a rule that is considered typical or common or acceptable) >> >> Of note: ODRL mixes Duty and Requirement together, specifies >> Obligation as applicability of a Duty, does not represent Promise or >> Law. I'm not saying it is incorrect, just that there may be an >> argument to make regarding not all obligations being duties or >> vice-versa, I'm not sure. ODRL also provides Request, Offer, and >> Assertion which I've skipped in above list. Maybe the above concepts >> are also of use for ODRL. >> >> # Even more terms >> >> As the list above makes clear, this can be a complex topic with a lot >> of navel gazing and endless discussions on what each specific concept >> actually means. Within DPV, we might want to focus on what is >> practically needed i.e. the ability to specify whether something is >> happening or not happening, and a way to enable other >> vocabularies/languages to express more complex rules over this >> information. >> >> The choice of "Permission" and "Prohibition" is more common because >> that's what we've been used to, but there are other also options: >> allow/deny, enable/prevent, approve/decline, and so on. Each concept >> (pair) comes loaded with interpretation that varies from that of >> permit/prohibit. >> >> RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) specifies similar >> interpretations for documents by using words like MUST, MUST NOT, etc. >> which ultimately boil down to: (a) something is a requirement; (b) >> something is prohibited; (c) something may happen; (d) something may >> not happen. >> >> # Deciding on *something* >> >> Since this entire exercise (and rabbit hole) started because I wanted >> to find a way to indicate something happens or doesn't happen, I >> suggest the following, based on RFC 2119 and ODRL. >> >> Parent class: Rule >> >> Requirement: MUST happen >> Prohibition: MUST NOT happen >> Permission: SHOULD or MAY happen, implied assumption it will >> Avoidance: SHOULD NOT or MAY NOT happen, implied assumption it will not >> >> Regards, > -- --- Harshvardhan J. Pandit, Ph.D Research Fellow ADAPT Centre, Trinity College Dublin https://harshp.com/
Received on Wednesday, 20 July 2022 17:15:20 UTC