PolicyHub outputs Offers, but EDC only supports Sets

[marcelruland]

Current Behavior

The PolicyHub currently outputs policies of ODRL policy subclass Offer. But the EDC only accepts policies of subclass Set.

Expected Behavior

The PolicyHub should output policies of an ODRL policy subclass which the EDC accepts.

Steps To Reproduce

Request any policy from the PolicyHub.

Further information

This relates to PR #224.

According to the CX ODRL profile, all three ODRL policy subclasses (Set, Offer, and Agreement) should be supported. However, currently only Set is supported by the EDC.

In ODRL, an Offer defines an assigner party, which in EDC terms corresponds to the provider. Defining an assigner in an asset policy (be it Usage or Access) is redundant, because the assigner is implicitly defined by whichever EDC has the asset in its catalogue. An Agreement in ODRL must have both an assigner (seller, provider) and an assignee (buyer, consumer). Defining an assignee does not make sense for an asset that is yet to be purchased (not even if it is being offered to only one specific party, because the purchase did not yet take place). A Set does not have to define an assigner, nor an assignee and appears to be the appropriate policy subclass for EDC assets.

This leads to the following questions:

• Should Offer and Agreement be valid in the CX ODRL profile?
• Should Offer and Agreement be supported as Access/Usage policies by the EDC?
• How should the PolicyHub handle the different policy subclasses?

Initially I do not see an advantage of supporting anything but Set as access policies, but I assume there was some rational behind making the PolicyHub return Offers specifically.

@MaximilianHauer @leandro-cavalcante

[MaximilianHauer]

topic is in discussion in the data sovereignty expert group. feedback will be given soonish.

[marcelruland]

Two short addendums:

Agreements are currently used to express contract agreements and that is a sensible use.

ODRL profiles can extend the language, but (as far as I can tell from the documentation) not restrict it. So (re-)defining existing policy subclasses does not seem to be intended. I don't know what the correct interpretation of this is in ODRL but in the best case it's redundant, in the worst case it's overriding the existing policy subclasses.