Policies like odrl:obtainConsent / remote policy evaluation

[matthiasdg]

Hi, I have some use cases where external parties need to approve negotiations or transfers. This can be expressed in a policy with odrl:obtainConsent, like in the examples on https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-g/usagecontrol/specification/concepts/t7_odrl_policies

I implemented this using the EventSubscriber; I check the policies e.g. on ContractNegotiationRequested on the provider, set the negotiation state on pending, dispatch a message to the external party and also created an api extension where the external party can (dis)approve. Upon approval the negotiation or transfer continues, upon disapproval it is terminated. This works perfectly and gave me more insight into the edc code base. Some things I noticed:

1. In a duty like (as per the linked examples):

"action": "use",
        "duty": [{
           "action": [{
              "rdf:value": { "@id": "odrl:obtainConsent" }
            }],
            "consentingParty": ["http://example.com/person/sara"]
            "constraint": [{
                "leftOperand": "event",
                "operator": "lt",
                "rightOperand": { "@id": "odrl:policyUsage" }
            }]
        }]

there can be this consentingParty. It seems this is currently not parsed by edc's Permissions/Duties; I found no way to access it. I didn't look into it because in my case the consentingParty is always the same. I just made it a configurable setting, but I guess there may be other cases where there can be other fields apart from actions/constraints? Or did I miss something?

2. If I terminate a transfer on the provider side before there is a DataFlow for it (e.g., upon TransferProcessInitiated), I get an error because it can't find this DataFlow in the store. Because of this, it then doesn't send a termination message to the consumer (processTerminating in TransferProcessManagerImpl). I just send it manually for now, but I'm wondering if it's a mistake on my end to terminate at this stage or if it should be supported behavior?

Thanks for the extensibility of the connector, once I got the hang of it, developing went pretty smooth!

[jimmarino]

Hi,

The link you highlighted refers to an old IDSA dataspace document not associated with the Dataspace Protocol Specification. The consentingParty is a function property not defined in the core ODRL data model but as a vocabulary. ODRL does not mandate support for function properties outside asignee and assigner. DSP also profiles ODRL, adding further restrictions. Open-ended function properties are not something we would likely support. That said, a similar behavior can be modeled by defining an explicit constraint. The constrain can be included on the contract policy or access policy (if approval should not be advertised).

Implementing a ContractNegotiationPendingGuard is the preferred way to implement manual workflows. The guard would block transitions from the REQUESTED state. The workflow would be responsible for transitioning the negotiation to ACCEPTING or another state. I am not sure what state pending refers to.

Regarding point 2, it is difficult to understand the sequence. If you think it is a bug, please file an issue with precise steps to reproduce, preferably a JUnit testcase using the EDC JUnit runner.

[matthiasdg]

@jimmarino thanks for the info on the ODRL (sorry for the late reply, was on vacation). I'm indeed using the PendingGuards (for both negotiation + transfer), and these result in the StatefulEntity set to pending, so that was not phrased precisely.

When I find the time I'll have another look at my point 2. Think it's just that in the current flow a transfer is only expected to be terminated when it's already started on the provider side, while with my manual flow, I sometimes terminate it from TransferProcessInitiated