Additional features of language

[renyuneyun]

trafficstars

Not sure if this is within the discussion range, but there are some useful features that do not exist in current ODRL. I'll illustrate them in separate sections below.

To be fair, they are the unique features from my previous work (especially perennial semantic DToU), and are proven useful there. Some reviewers asked if it's possible to use ODRL to represent the language, and I found it not possible. But generally they expect languages could be unified as much as possible (which I agree), so I'm proposing this here in case some of them are within consideration.

Metadata-style attribute

Instead of referencing to environmental information as attribute, the policy carries some meta-data as attributes. This allows reusable information within the policy, and also enables additional features for the psDToU language (and previous work), e.g. policy derivation (see below).

Internal referencing as operand

This is related to the above, where the operand of logical operators should be able to refer to an attribute. This is not possible in current ODRL, because (left) operand has to be a predefined term in some vocabulary, which is not compatible with the desired new feature.

Distinguish between "data/provider policy" and "application/consumer policy"

Current ODRL has "Set", "Offer" and "Agreement". It distinguishes between "status", but cannot be used to represent the semantics/information of:

• Data/Provider policy: This policy is set by the data provider, representing some expectations and rules that they wish the data consumer should follow;
• Application/Consumer policy: This policy is set by the (prospected) data consumer, representing the actions or rules that the consumer would perform or follow.

This is not a small change, as it changes the view of a policy language / engine:

• Current ODRL: A language/engine to perform compliance checking (and other reasoning tasks) to verify that the specified policy (about data) is followed by the context (and also the language to capture such policies);
• psDToU/pDToU: A language/engine to perform compliance checking (and other reasoning tasks) to verify whether the policy set by the data provider is being complied with by the policy gave by the data consumer (and also the language to capture such policies).

Note that data consumption may not have been started when policy engine is doing reasoning. In fact, psDToU/pDToU would allow policy checking while the user is being asked whether they want to authorise the application to use their data or not (as demonstrated as a custom Solid service component; also possibly done as UMA module).

Policy derivation

Because all useful data processing will produce output data, the policy engine had better support automatically deriving of policy for output data. The derivation can be dumb, such as copying the policy for input while only changing the data identifier. It can also be smart, which takes into consideration of the actual processing happened.

In psDToU, this is supported through taking the advantage of having "app policy" and "attribute", where special constructs are used to inform such information.

In addition, policy merging should also be considered, as input data may come from multiple sources each with different policies.

Other

There are some other mechanisms, but they are subject to the existence of those above. I'll reserve that for the future if the above sounds interesting to ODRL community.

[joshcornejo]

Quick questions/comments:

• Metadata-style attribute: what is the need for this to be integral to the policy (will try to read your work)
• Internal referencing: don't understand the use (probably clarity when i read your work)
• Provider/consumer policy: sounds like a specific use case and perhaps could be addressed as a profile with extensions
• Data in and out should represent some type of defined asset, and policies "out" should comply with all requirements from policies "in" on the subsets of the assets generated ... that (I assume) is already possible.

[vroddon]

I dare to label the issue as ODRL3.0 and invite participants to provide feedback on Rui's work.

[riannella]

1. ODRL supports metadata: https://www.w3.org/TR/odrl-model/#metadata
2. How can the left operand not be known? How can you modeL something if you don't know the property?
3. Provider/Consumer - create a Profile - define your Policy types
4. Some support in Policy inheritance: https://www.w3.org/TR/odrl-model/#inheritance

[joshcornejo]

IMHO (3) has a lot to do with individual interpretations of a role ... sort of having equivalencies or synonyms in a profile as you mention, unless there is a set of actions that are specific.

[renyuneyun]

Thanks guys for the comments. I'll try to reply by grouping relevant topics. Also, I'd like to share the spec and documentation of psDToU language as well as its integration with Solid, which has some examples and (probably) better diagrams.

Metadata-style attributes

Metadata-style attribute: what is the need for this to be integral to the policy

ODRL supports metadata: https://www.w3.org/TR/odrl-model/#metadata

It's needed mainly for enabling some other mechanisms. In particular, the "binding" mechanism requires this, and some other related mechanisms in App Policy.

"Binding" is from a rule, pointing to one or more attributes/metadata, meaning the rule is valid only when these attributes/metadata exist. It's different from having a constraint pointing to the attributes/metadata (with sufficient modification of constraint syntax), because of the policy derivation mechanism (and the corresponding point of view of the policy architecture).

In addition, this also forms reusable pieces of information, to be referenced across different rules (permissions, prohibitions, obligations). In psDToU, there is also the "tag" mechanism that uses attributes, though it doesn't have to.

So, the current metadata mechanism of ODRL seems to be a valid starting point, though it's not the same types of information. The current ODRL metadata specifies information about the policy, not information contained in / carried with the policy. It is also difficult to use for policy derivation, when we talk about the "refinements" in the App Policy.

Internal referencing & operand of the metadata-style attribute

Internal referencing: don't understand the use (probably clarity when i read your work)

How can the left operand not be known? How can you modeL something if you don't know the property?

The left operand is known, but not as a static information in a vocabulary. In fact, when I think further into this, I feel describing it as left operand (in a constraint) is not the right way.

What I really want here is: a generic (de)referencing mechanism, that can be used in many places in different rules. That includes: as parameters to the rule itself (e.g. obligation details / refinements), as the "binding" mechanism, and potentially in constraints as well. So, that kinds of relates to ODRL's refinement and constraint, so that's why left operand was brought into discussion.

When I think about it further, the closest way I can think of for parameterizing is like this, if trying to use ODRL:

(Report the use of the date of birth field, if it exists in the policy.)

[] a odrl:Policy;
  odrl:attribute ex:attr1;
  odrl:obligation [
    odrl:action [
      rdf:value odrl:reportUse
    ];
    odrl:refinement [
      odrl:leftOperand odrl:arg1;
      odrl:operator odrl:ref;
      odrl:rightOperandReference ex:attr1
    ];
    odrl:constraint [
      odrl:and [
        odrl:leftOperand odrl:binding;
        odrl:operator odrl:ref;
        odrl:rightOperandReference ex:attr1
      ]
    ]
  ].

ex:attr1
  odrl:name ex:column;
  odrl:value ex:dateOfBirth.

As can be observed, new terms need to be added (odrl:attribute, odrl:name, odrl:value, odrl:binding, odrl:ref, odrl:arg1), and some terms (odrl:leftOperand, odrl:rightOperandReference, odrl:constraint) should be interpreted differently from how they are defined in ODRL 2.2.

Provider / Consumer policy

Provider/consumer policy: sounds like a specific use case and perhaps could be addressed as a profile with extensions

Provider/Consumer - create a Profile - define your Policy types

I always struggle to understand how much a profile can do in ODRL, which is also part of the reason for raising this discussion -- asking for some comments.

In my current understanding, an ODRL profile can be used to define custom subclasses of ODRL concepts, whether it's subclasses of existing ODRL classes (e.g. Policy, obligation), ODRL properties (e.g. operator), and vocabularies (e.g. actions, purposes). That is far from what the separation of a provider / consumer policy needs, as that probably involves completely different semantics. The intuition for this separation in psDToU is:

• [Data Policy]: Data provider has some intrinsic expectations on how they want their data (e.g., by dataset, data types, etc) to be used or not to be used, and that's often the same across different apps (e.g. I want my credit card details to be used only for verifying or making payment; I permit my shoe size to be used for any purpose);
• [App Policy]: Data consumer / App has their logic written, and won't often change; the logic reflects how they handles the data (e.g. what actions, for what purpose, by which party); that's usually the same across different data providers / users;
• [Structure / Concepts]: Because they describe different types of information, the policy structure should be different for them, to fit their own needs.
• [Reasoning]: The two policies will be checked against each other for their compliance/compatibility, potentially taking into account of environmental information.

In the first glance, ODRL only has components similar to the Data Policy, through the Policy and Set class (the examples in the previous section are all about this). Later I was told there is Request class, somewhat similar to the App Policy, but couldn't find lots of explanations / resources / examples. (Only found examples here in Ghent team's ODRL Evaluator.) So, that gives me a hard time to understand how well the relevant ODRL constructs may align with psDToU (and/or vice versa) in this case. It occurs to me:

• ODRL is mainly designed assuming an overarching status of "I have a policy set written in ODRL, and I want to verify if the data processing environment / procedure is compliant with it or not". Apart from Policy and Set, to some degree, this also fits with the Offer class, as there is still one set. But it's very different from the assumption psDToU holds.
• For the Request class, what is its semantics? Is it still the same idea that "the request is one policy set that aims to be checked against the environment"? Or, is it having a different semantics that describes "these are the rules I will follow when using this specific data" (note the difference between policy that can be evaluated, vs a policy that describes information, that is not necessarily evaluate-able on its own)?
  • Further comment: if it's interpreted in the same way, it means both the Request policy (from data consumer), and the other policy (from data provider) are both complete ODRL policies (in the common way), and both needs to be (individually) verified/evaluated against the environment.

So, am I understanding it correctly for ODRL? If not, are there any resources/examples on why?

Policy derivation

Data in and out should represent some type of defined asset, and policies "out" should comply with all requirements from policies "in" on the subsets of the assets generated ... that (I assume) is already possible.

Well, that's different. First I accept the assumption that each rule in the policy is tight to a specific target / dataset.

But please let me remind that the output data and input data are different artifacts / targets, with different IDs. The policy of the input data does not talk anything about the output data, nor will it know the ID of the output data. Let's call the original data dataset1, its policy policy1, and output dataset9.

Therefore, by the time the output data is generated, and policy evaluation (and other inference) is done, we have dataset1 and dataset9, and policy1 constraint / bound to dataset1. I don't see how and why we will have a policy bound to dataset9.

Unless, there is an implicit assumption, that the policy engine / software platform will automatically copy and modify the input policy, and change all identifiers from dataset1 to dataset9 (as well as all substructures of them, if any, assuming there is a magical way to do this). Is that what you mean? But that's not what ODRL provides or defines. It's a custom piece of software. (It also lacks the part about flow specification and refinement. But that's a secondary thing.)

Some support in Policy inheritance: https://www.w3.org/TR/odrl-model/#inheritance

Thanks for pointing to that. I did read about it. But to this topic, this is a mechanism for policy reusing/composition, rather than policy derivation. I like it in that way, but it's quite different -- especially for the discussion above about IDs of artifacts.

There is also a potential issue of efficiency, if data is used in a complex workflow (across many users), if this mechanism is used here.

Unbounded policies

Related to the discussion above about IDs of artifacts for policy derivation, there is a related important design difference between ODRL and psDToU:

• In ODRL, the assigner and assignee are explicitly encoded (and usually expected), and is a whitelist-like mechanism -- if the actual user is different from the assignee, it's prohibited. This means the policy needs to be re-written for every different user, particularly data consumers.
• In psDToU, the assigner and assignee are not explicitly encoded, and is a blacklist-like mechanism -- if the actual user is not mentioned in the constraints, it's permitted. This means the policy does not need to be re-written for every different user; the mechanism is there for both the data provider and data consumer.

A viable way is to take this as a layered/staged approach (see, e.g., #105), where, e.g., psDToU describes a general layer for "whether the data request should be permitted or not", and ODRL acts as the enforcement/contract layer for "constraining and proving that the said operations can be performed by the data consumer". Of course, it needs to be figured out how this mapping or instantiation to ODRL can be performed, and what corner cases needs to be handled -- e.g., policy derivation.

(That's a viable direction for ODRL 3 to go, to contain both constructs for general policy, and specific policy, to make the instantiation process easier.)

[joshcornejo]

My musings:

Metadata-style attributes

It's needed mainly for enabling some other mechanisms.

From the explanation, it isn't clear what are those "other mechanisms" or what tangible examples are for ""Binding" is from a rule, pointing to one or more attributes/metadata"

Without such example, I think these belongs in a profile or is not even relevant to the actual policy/rule.

In the work I've done I have 2 types of metadata: some related to the ODRL level (e.g. dc:creator) that seem more "admin of policy/rule" and the other completely irrelevant to ODRL (e.g. "this assigner wants rules routed to this queue for logging" - these is not even necessarily expressed in RDF, as it is to be "consumed" by 3rd parties, and it can be up to them to define what they want to do).

I think perhaps an example is useful.

Internal referencing & operand of the metadata-style attribute

Sorry - still don't understand and your policy with refinement/constraint is valid RDF but invalid ODRL (you're not refining anything).

I would suggest (at least for my understanding) that you create a "this is how it looks in ODRL vs this is how i propose it to look".

Provider / Consumer policy

This one is too broad - perhaps a discussion is better (some of your understanding is correct, some of the explanations you give are confusing).

But ODRL has proposed extensions with new types of rules:

• https://www.w3.org/2012/09/odrl/archive/odrl.net/Profiles/Services/WD-20080402.html
• https://ai.wu.ac.at/policies/orcp/regulatory-model.html

Policy derivation

This one is a subset of the topic around change management, but at it's simplest you can think that the policy is a "bag of groceries" with onions and potatoes - the rules for the each can be independent or mixed.

I can create PotatoPolicy and OnionPolicy ... and then also have either:

• RootsPolicy :inheritFrom PotatoPolicy, OnionPolicy

• RootsPolicy has all the rules from each policy and is independently managed, when I sell Potatos or Onions I use individual policy, when I sell both - I can use RootsPolicy.

Here you also have to consider :refinement ... You can see my example of how multiple rules, pointing at different nodes end up having the same "target".

• https://github.com/w3c/odrl/issues/129

Unbounded policies

You can also rephrase that ODRL is a "zero-trust" mechanism, which is the one everyone prefers in security.

Your statement that "This means the policy does not need to be re-written for every different user" is incorrect - you can have policies for groups (and again - refinements of groups), so 1 agreement can cover anyone (e.g. "All data for EU users can't leave the EU" could be 1 rule in 1 policy for everyone, not 400M policies - obviously the "processor/state of the world" needs to have a reference to such policy).

[renyuneyun]

I think things are entangled -- examples for one aspect involve quite some introductions to many aspects. But I'll try to illustrate.

Metadata-style attributes

I'll use two examples (from simple to more complex) to illustrate two types of "usage" of such attributes, including what "binding" means.

"Reference" from a "Tag"

So here is an example, saying that the data (omitted) can be used only when the app respects voc:banking security level:

ex:tag2 a dtou:SecurityTag;
    dtou:attribute_ref ex:attr-tag2.

ex:attr-tag2 a dtou:Attribute;
    dtou:name voc:tag-2;
    dtou:class voc:banking;
    dtou:value voc:nil.

The "tag" mechanism is used to specify things about DIFC (see, e.g., CamFlow for further examples in others' systems). For this example, it specifies a SecurityTag, of value voc:banking (by referencing to the ex:attr-tag2); SecurityTag means the data consumer must also provide a SecurityTag no less strict than voc:banking.

So here, the dtou:attribute_ref properties is used to provide a reference. Of course, there are viable ways to encode this information within the Tag itself, but there are additional benefits of using an attribute (see later at policy derivation).

"Binding" from a Tag

Extending the previous example, this one not only specifies the tag itself, but also specifies the tag has a "binding" to an attribute ex:attr2:

ex:tag2 a dtou:SecurityTag;
    dtou:attribute_ref ex:attr-tag2;
    dtou:validity_binding ex:attr2.

ex:attr-tag2 a dtou:Attribute;
    dtou:name voc:tag-2;
    dtou:class voc:banking;
    dtou:value voc:nil.

ex:attr2 a dtou:Attribute;
    dtou:name voc:det; 
    dtou:class voc:data-content; 
    dtou:value voc:payment-details.

So, what this means is that, in addition to what has been explained before, the tag ex:tag2 will be available only if ex:attr2 exists in the data policy. In other words, if ex:attr2 cease to exist, ex:tag2 will cease to exist as a consequence. (Again, the mechanism that makes an attribute cease to exist is at policy derivation.)

Internal referencing & operand of the metadata-style attribute

Sorry - still don't understand and your policy with refinement/constraint is valid RDF but invalid ODRL (you're not refining anything).

Thanks for pointing it out. I put the refinement at the wrong level. It should be with the action. So, the corrected one would be:

[] a odrl:Policy;
  odrl:attribute ex:attr1;
  odrl:obligation [
    odrl:action [
      rdf:value odrl:reportUse;
      odrl:refinement [
        odrl:leftOperand odrl:arg1;
        odrl:operator odrl:ref;
        odrl:rightOperandReference ex:attr1
      ];
    ];
    odrl:constraint [
      odrl:and [
        odrl:leftOperand odrl:binding;
        odrl:operator odrl:ref;
        odrl:rightOperandReference ex:attr1
      ]
    ]
  ].

ex:attr1
  odrl:name ex:column;
  odrl:value ex:dateOfBirth.

I would suggest (at least for my understanding) that you create a "this is how it looks in ODRL vs this is how i propose it to look".

That's roughly what I was trying to illustrate with the example. But it's not "ODRL now vs ODRL future", because a) I don't know if ODRL (2.2) can reprecent it or not; b) I don't think ODRL (2.2) can represent it. I was trying to illustrate the closest thing I coud think of, reusing as much ODRL constructs as possible (but having to extend it).

Provider / Consumer policy

This one is too broad - perhaps a discussion is better (some of your understanding is correct, some of the explanations you give are confusing).

Sure, happy to have the discussion at where ever appropriate. As I said above, indeed one of the main goal of this thread/issue is to also concretize my understanding of ODRL. Also, thanks for pointing to the two profiles. I had a quick read of them, and it appeared they confirmed my understanding: profiles only create new subclasses (or extending existing classes with new properties). That is not sufficient for the discussion here.

Policy derivation

I don't disagree with what you have said. In fact, that's some fundamental requirements of either policy composition or policy derivation.

But a problem with ODRL (2.2) is: the policy has assigner, assignee and target, and inherit happens on the policy level. That will also inherit the assigner, assignee and target. This can be problematic, which is a key issue for doing policy derivation. You cannot have a policy that should apply to target dataset9, but inside it saying targeting dataset1, because it inherited from the policy targeting dataset1.

I think #129 is along a similar path, but it did not discuss this aspect. That means, it can enable policy reusing when talking about exactly the same dataset target, but not policy templates that do not target a specific dataset at the form it is written.

Unbounded policies

You can also rephrase that ODRL is a "zero-trust" mechanism, which is the one everyone prefers in security.

Well... It's not zero-trust... That's quite different concepts... If you really want zero trust, you need to have a mechanism inside ODRL to verify who is using the data under what condition for what activities (rather than using an external system to inject the environmental information). Most access control or usage control (or etc) systems are not zero trust; neither is the psDToU.

Your statement that "This means the policy needs to be re-written for every different user" is incorrect - you can have policies for groups (and again - refinements of groups), so 1 agreement can cover anyone (e.g. "All data for EU users can't leave the EU" could be 1 rule in 1 policy for everyone, not 400M policies - obviously the "processor/state of the world" needs to have a reference to such policy).

I agree ODRL (2.2) can do that in static cases. But you have also pointed it out: in the policy, I still need to specify the group (as a collection). When there is a new user, what would you do? Silently / Stealthily modify the group resource to include the new user, or create a new policy?

[joshcornejo]

Well... It's not zero-trust... That's quite different concepts... If you really want zero trust, you need to have a mechanism inside ODRL to verify who is using the data under what condition for what activities (rather than using an external system to inject the environmental information). Most access control or usage control (or etc) systems are not zero trust; neither is the psDToU.

ODRL is authorisation, not authentication... the policy doesn't need to verify "who is" because that is the problem of the authentication (oauth or verifiable credentials) ... the part of zero-trust is related to the references within - the parties and targets mentioned in the policy.

Zero Trust is a modern security framework and philosophy based on the principle of "never trust, always verify".

There is nothing in zero-trust that says that "one solution must do it all" (authentication doesn't do authorisation and viceversa).

[besteves4]

Hey @renyuneyun, for the internal referencing check the solution that @woutslabbinck and I propose in https://spec.knows.idlab.ugent.be/odrl3proposal/latest/#r2 (it's also in our recent May the FORCE be with you paper)