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: https://github.com/w3c/odrl/issues/21 which raises the question for ODRL for the case mentioned in https://github.com/solid/specification/issues/355#issuecomment-1140508784 .

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.

[coolharsh55]

Coming back to this, I think there is merit in representing the outcome of a matching process - though making it broader beyond Policy is beneficial for other use-cases. I'm thinking that we have RuleMatchingStatus to represent the status of matching rules - here 'Rule' is a broad term that can mean a set of rules, a policy, a process, or something else.

1. MatchingOutcomeUnknown - the matching outcome is not known.
2. RuleMatchingSatisfied - the matching outcome is that all conditions are satisfied based on a contextual interpretation (more on this later).
3. RuleMatchingUnsatisfied - the matching outcome is that all conditions were not satisfied and there were some violations or unsatisfiable conditions.
4. RuleMatchingPartiallySatisfied - the matching outcome is that some conditions were satisfied, and other conditions were not violations and no unsatisfiable conditions were found.
5. RuleMatchingUndeterministic - the matching outcome cannot be derived as it is undeterministic i.e. cannot be computed or cannot be done within specified conditions (e.g. limited time).

In the above, if we compare user policy with a provider policy, and the outcome is anything other than RuleMatchingSatisfied - the user can be alerted to take action (which addresses your first comment).

Further, the matching process also needs to take into account different modalities for checking permissions, prohibitions, and obligations between the user and provider policy, as well as between the user's multiple policies. E.g. the user may not have a single rule/policy, but may have multiple based on some structure e.g. within a folder, then within a subfolder, then for a specific asset/resource. How should the comparison algorithm operate?

Priority between Permission and Prohibition over same resource: if there is a path docs/contacts and there is a policy for docs and another policy for contacts then what should be the overall interpretation of both policies for either docs or contacts. Here if both policies have permission, then the outcome is permission - same for prohibition. So the below table only shows the outcome when the two policies have differences. Y represents permission, N represents prohibition. Based on these, the user's multiple policies can be resolved to get a consistent outcome on whether access to docs or contacts should be allowed.

1. Strong permission means permission overrides prohibition regardless of direction
2. Strong prohibition means prohibition overrides permission regardless of direction
3. Acquired Prohibition means inherited permission does not override prohibition, but prohibition of child does apply to the parent
4. Equivalent means inherited permission and prohibition from parent do not override prohibition or permission in child, and prohibition and permission of child do not apply to the parent (seems most pragmatic)
5. More exist but I have highlighted these to show there is a choice to be made here.

modality	policy-docs	policy-contacts	access-docs	access-contacts
strong-permission	Y	N	Y	Y
strong-permission	N	Y	Y	Y
strong-prohibition	Y	N	N	N
strong-prohibition	N	Y	N	N
acquired-prohibition	Y	N	N	N
acquired-prohibition	N	Y	N	Y
equivalent	Y	N	Y	N
equivalent	N	Y	N	Y

Default interpretation: if docs has a policy and contacts doesn't, then what should be the interpretation - and vice-versa?

1. Default Permission: If no condition is present in any parent, then the default is permit.
2. Default Prohibition: If no condition is present in any parent, then the default is prohibit

[besteves4]

this has strong ties with what we are working on in the ODRL formal semantics sub-group and in particular with the ODRL evaluator implementation we are developing at UGent. I would like for this to go hand in hand with that development so that the concepts are aligned and there is no duplicity

[ghurlbot]

Comment by @coolharsh55 via IRC channel #dpvcg on irc.w3.org

this is related to ongoing work in ODRL CG - therefore we will wait for that work and reuse / integrate it here