Expressing preferred policies or templates

[csarven]

User wants to check whether the storage's policies are compatible with their own preferred policies. If there are any discrepancies, the user should be warned and given a chance to make a decision about available options.

Does DPV provide a solution that meets the requirements of this use case?

See also: w3c/odrl#21 which raises the question for ODRL for the case mentioned in solid/specification#355 (comment) .

Thinking along the lines of preferred rights, processing rules, purpose, and so forth.

[coolharsh55]

Hi Sarven. To better understand what you're asking, I will try to break down the question into more granular ones to clarify what the requirements might be.

1. Can the DPV express separate policies for user and provider? Ans: No, it doesn't specify "ownership" of a policy, but this can be done by subclassing e.g. dpv:PersonalDataHandling to ex:UserPolicy and ex:ProviderPolicy.
2. Can the DPV express preference of one policy over another? Ans: No, this is tricky to do in general. What does preference mean, in what context and condition, and how are preferences resolved? In general, DPV provides dpv:hasPolicy to help with specifying something or someone has a policy (which can be aligned with your linked issue in ODRL). Additionally, if policies are being modelled in DPV, I would use dpv:ActivityStatus to indicate whether the policy (as a process) is in operation, or is halted, or is completed, etc.
3. Can the DPV express the outcome of a policy match? Ans: Yes, we added concepts about dpv:ComplianceStatus to v0.7 i.e. something is compliant, partially compliant, or not compliant. Perhaps these would be helpful to determine what action to take i.e. refuse access (non-compatible policies) or to ask user (partially compatible policies).
4. Does the DPV provide a way to represent the differences between two policies? Ans: No. I'm not aware of any work that does this either. But, perhaps, if the set of comparisons is limited, then there can be further subclasses of the compliance concepts from above to specify what kind of discrepancy exists, e.g. PurposeNotCompatible, PurposePartiallyCompatible, DataNotCompatible, and so on. This can further help decide next action (e.g. whether to ask user).
5. Does the DPV provide a way to represent the decision i.e. what was done by the user - accept, reject, etc.? Ans: Not currently, but there is proposed work coming that provides these concepts in terms of consent based on recent ISO developments. You're aware of statuses in GConsent, so these would be similar to those.

For the concepts not in DPV in above, You/We can propose addition of these concepts (the names may change) if this fits the requirements.

[coolharsh55]

@csarven are there any further points/actions for this discussion? If there are no more actions for this discussion, I will mark it as resolved on OCT-15 as part of a general cleanup of issues.

From the above, pt.5 has been implemented in the form of ConsentStatus to express consent is given, refused, etc. The rest concerning handling of policies, which we have not yet discussed as to if it is in our scope. Though it definitely is in ODRL's scope AFAIK.

[csarven]

This is essentially about enabling our tools to help us make informed decisions.

Welcome to use a term that's more suitable than "preferred".

Can the DPV express separate policies for user and provider? Ans: No, it doesn't specify "ownership" of a policy, but this can be done by subclassing e.g. dpv:PersonalDataHandling to ex:UserPolicy and ex:ProviderPolicy.

Separating policies can be useful but that wasn't my core concern. The focus is on the kind of relationship that's drawn between an entity and a policy. It is generally about an entity specifying or requesting a policy.

What does preference mean, in what context and condition, and how are preferences resolved? In general, DPV provides dpv:hasPolicy to help with specifying something or someone has a policy (which can be aligned with your linked issue in ODRL).

Those are the kind of things I'd like to understand better too. Tricky indeed.

An entity's policy preferences is intended to be used by anything (e.g., person, social entity, software) that has the authority (or delegated) to act on behalf of the entity. A preference can be resolved if there are no semantic conflicts with between a preferred policy and a specific policy.

Perhaps the notion of a "policy template", which could be a dpv:Policy provided that the data model provides additional context and conditions in which an entity engages with something, or alternatively something like dpv:PolicyTemplate.

My understanding of dpv:hasPolicy doesn't seem to be usable by social entities (e.g., identifiable individuals or groups, like with a WebID), but happy to be corrected on this. That property has dpv:Concept as domain. For the use case, I'd expect something along the lines of dpv:Entity dpv:hasPolicy dpv:Policy.

Can the DPV express the outcome of a policy match? Ans: Yes, we added concepts about dpv:ComplianceStatus

Does the DPV provide a way to represent the differences between two policies? Ans: No. I'm not aware of any work that does this either. But, perhaps, if the set of comparisons is limited, then there can be further subclasses of the compliance concepts from above to specify what kind of discrepancy exists, e.g. PurposeNotCompatible, PurposePartiallyCompatible, DataNotCompatible, and so on. This can further help decide next action (e.g. whether to ask user).

Indeed seems useful towards resolving preferences.

From the above, pt.5 has been implemented in the form of ConsentStatus to express consent is given, refused, etc.

Great! What I'm sensing is that there is material to indicate the result of the application of a preference policy. We just need some glue to help applications to make decisions - when an entity encounters a policy, the entity checks that policy against its own policies. There can be different ways to discover the preferred policy. Through the entity's profile seems reasonable and usable to me.

[coolharsh55]

Hi. I think I understand more about what you're expressing here after reading through the Solid data interop specs. So in that sense, dpv:Policy is not the same as an Access Control Policy (ACP), but rather an expression that some concept has a policy attached or associated to it. For example, Entity has policy (e.g. describing privacy policy), Data has policy (e.g. describing storage condition), or Individual has policy (e.g. describing personal preferences and decisions). What actually goes on inside each of these policies should be expressed using dedicated concepts, and requirements over those. For example, an App's policy is a request to use data, whereas' the Individual's policy is their side of preference/conditions. This is from the 'contract' or 'transaction' notion of agreements - which again goes into ODRL territory. So, the use might be, e.g. DPV to describe the contents and ODRL or any other language to describe the policy structure/rules.

Perhaps the notion of a "policy template", which could be a dpv:Policy provided that the data model provides additional context and conditions in which an entity engages with something, or alternatively something like dpv:PolicyTemplate.

'Template' in what sense? Do you mean a 'schema' or an 'ontology' that gets applied to create policies for specific things? Or also some 'rules' and 'constraints' to dictate/validate what data should go into it? IF any of this is yes - it is tricky to define these because of variances across use-cases, jurisdictions, and technologies. So rather than adding templates to DPV, IMHO the implementation should be done externally, e.g. a profile for Solid that uses DPV's structure and concepts and dictates how these should be used in its applications. This requires an additional vocabulary that maps the domain (e.g. Solid) concepts to DPV (and through it to legal stuff, e.g. GDPR).

From the above, pt.5 has been implemented in the form of ConsentStatus to express consent is given, refused, etc.

Great! What I'm sensing is that there is material to indicate the result of the application of a preference policy. We just need some glue to help applications to make decisions - when an entity encounters a policy, the entity checks that policy against its own policies. There can be different ways to discover the preferred policy. Through the entity's profile seems reasonable and usable to me.

Yes, but my statement was only about consent. What you're describing should be a negotiation / policy language in general, that has specific interpretation for consent. Otherwise non-consent use-cases will not be able to function or use this efficiently. So there has to be a 'well-known' IRI or way to retrieve information about an entities' (well, a company, not an individual) policy or policies. Then the policies must be structured using a well-known schema, and must use well-known vocabularies (this is where DPV fits in) - to make interpretation and interoperability possible.

We can generalise this discussion for DPVCG to instead consider creating such 'well structured' policy 'shapes' to make the above discovery + negotiation + decision flows possible - which gives a concrete action/task to aim towards. This would be wonderful and novel to, and I'm willing to be involved in this (and it is very much of interest) - but I also have to look after the other aspects of DPV - so this will require more time/volunteers to get done.