Implement the Policy Library and Connectors on the Frontend
We received new information from 1001 Lakes and Tecnalia regarding the Policy Library and the Connectors of the Data Products, as mentioned below:
EDC Connector Feedback
Policy Library
Feedback do Joel sobre as Policies:
The premise we agreed on today in Bilbao is: during the creation of a data product / contract definition, the user will create and attach a policy to the data asset. Based on the policy engine extensions (=what rules we can evaluate), the user can choose to restrict the use of their asset in one or more (or none) of three ways: time interval, location, and purpose. The user chooses the rule(s) they want to add to the policy, and specify the required parameters for each rule:
Time interval: start DateTime, end DateTime Location: permitted location(s) Purpose: permitted purpose(s)
This data is then sent to the policy library backend, where it is used to populate a Permission template and added to the final ODRL document.
I don’t know if this is an actual problem, but it’s pretty restrictive and doesn’t use the full potential of the policy engine extensions. My idea was the following:
In addition to specifying the parameters required by each rule, could the user also specify, whether they want to permit (the example above) or prohibit the specified parameters? Let me illustrate with two examples.
Let’s first consider the case of permitting use for a specific location, the EU. The user chooses to add the location rule to the policy, turns the permit/prohibit switch to “permit”, and selects “EU” form the location dropdown. This would cause the backend to add the rule
“permission": [{ "action": "Use", "constraint": [{ "leftOperand": "dateTime", "operator": "eq", “rightOperand": “EU” }] }]
to the final ODRL policy.
What if the user wants to prohibit use for a specific location, say the US? Let’s take it from the top. The user chooses to add the location rule to the policy, turns the permit/prohibit switch to “prohibit”, and selects “US” form the location dropdown. This would cause the backend to add the rule
“permission": [{ "action": "Use", "constraint": [{ "leftOperand": "dateTime", "operator": "neq", “rightOperand": “US” }] }]
to the final ODRL policy. This would now mean that use is permitted as long as you are not located in the US, whereas in the first case use is permitted as long as you are located in the EU.
AFAIK the policy engine extension functions already support negation checks, the following is from the location function:
return switch (operator) { case EQ -> Objects.equals(region, rightValue); case NEQ -> !Objects.equals(region, rightValue); case IN -> ((Collection<?>) rightValue).contains(region); default -> false; }; So in short, adding the permit/prohibit switch (or however we want to implement this) to the frontend would double the expressive power of the policy creation UI. What do you think?
//Joel
PS: I don’t speak fluent Java, but I think the switch-case-structures in the policy engine extension functions are missing a check for a case where the given element is not part of a collection, i.e. a negation of the case IN -> ... I guess the ODRL operator for that would be isNoneOf? And expanding from there, wouldn’t the EQ / NEQ cases then be redundant, because they would be just special cases of the collection checks, where the size of the collection is 1?
Feedback da Urtza sobre Policies:
I'll try to include the operator you mention, "IS_NONE_OF." As you say, EQ and NEQ are redundant if you're going to use the IN and IS_NONE_OF operators. If you don't mind, I'll keep them and include the new one. I'll run the tests on a local connector and when I've tested everything, I'll upload it to the Datamite Git and let you know it's ready to use.
I've attached the "Operator.java" class in case you want to see which operator can be used and what's included in the EDC policy model.