juliapampus
commented
2 years ago Tried to note down some observations, past discussion outcomes, and next steps @jimmarino.
Policy Language in IDS
- IDS extends ODRL: the IDS Usage Control Language was initially defined as a profile of the ODRL language.
- Referring to this comment, IDS introduces pre- and post-duties that could, nevertheless, be mapped to ODRL.
- In IDS, it was tried to map use case requirements to policy classes (see here for templates) and thus, attributes as the left operand or actions were restricted to a number of enums that seemed reasonable.
Action: IDS vs ODRL
Taking a look at this documentation, this is the current status:
Action: A thing one might be permitted to do or prohibited from doing to something.- has super-classes: action
- is in domain of: action refinement, is included in
- is in range of: action, is included in
- has members: aggregate by consumer, aggregate by provider, anonymize, compensate, delete, distribute, ecrypt, grant use, log, modify, next policy, notify, read, track provenance, use, write (16)
ODRL defines top-level actions (use, transfer). According to the documentation, Action terms must be defined using the includedIn property referring to an encompassing Action and either use or transfer as the top-level parent term by transitive means. Details on the includedIn and implies properties can be defined by ODRL profiles.
The ODRL vocabulary defines 72 action types. Some of them appear in IDS, a lot of them not. On top of that, IDS defines other actions (marked cursive).
LeftOperand: IDS vs ODRL
Taking a look at this documentation, this is the current status:
LeftOperand: Instances of the LeftOperand class are used as the leftOperand of a Constraint.- has super-classes: left operand
- is in domain of: broader LeftOperand
- is in range of: broader LeftOperand, leftOperand
- has members: absolute geo-spatial position, count, current event, delay, elapsed time, endpoint, execution system, path to attribute, payAmount, payment, policy evaluation time, purpose, quantity, recurrence rate, security level, state, user (17)
broader LeftOperand: This LeftOperand is transitively included in the object LeftOperand.
The ODRL vocabulary defines 34 operand types. Same as for actions, some of them appear in IDS, a lot of them not. On top of that, IDS defines other values.
Problem
- The EDC wants to support full ODRL independent from a specific use case. Mapping an ODRL policy to IDS as-is causes information loss in a way it should not. If IDS simply extended ODRL, one could argue that not supporting IDS features is bad but a design decision. However, any information originally expressed in ODRL should be mappable to IDS.
- Members of an IDS Infomodel object are expressed as Java enum classes (in the IDS Infomodel libraries). Thus, custom values cannot be set.
Possible Solution
Long-Term
- Alignment of definition and identifiers for IDS actions and leftOperands (and other attributes that may be restricted by IDS).
- Steps to put into practice:
- Change IDS Information Model: new release (v5.x.x.?).
- Adapt IDS Infomodel CodeGeneration and IDS Infomodel Serializer to support new IDS Information Model version.
- Integrate new libraries into EDC.
Challenges
- Adaptations cannot be integrated in IDS Infomodel v4 because of breaking changes.
- New IDS Infomodel v5 will bring more changes than that.
- No release date for v5 planned for now.
- Work for alignment needs to be done first (difficulties are not to be underestimated because IDS interprets values different from ODRL and thus cannot use the same terms).
Current Work
- IDS Information Model clean up: usage of application profiles; remove duplicated identifiers, use existing (e.g. ids:mediaType to IANA MediaTypes)
- Alignment of ODRL and IDS actions (document in IDS ThinkTank, not accessible -> maybe you could make this a public discussion @Brandstaedter?)
Short-Term ("Quick Fixes")
EDC
- Possible (very bad) workaround for the moment: All java classes (Infomodel lib) support a properties map. An "odrl to ids"-transformer could insert the ODRL Action/leftOperand as a custom property of an fix IDS Action/leftOperand. An "ids to odrl"-transformer knows that and takes this property to map it back to odrl. So in general, we just "forget" all IDS enums and only use the ones from ODRL.
IDS java libraries
(not sure what can be implemented and how)
- Change the IDS Infomodel CodeGeneration (and thus also the serializer) to provide a wrapper class. This could expect the pre-defined enums, but also custom strings - and map this to json-ld.
- Change the IDS Infomodel CodeGeneration (and thus also the serializer) to enrich enum classes with the possibility to add custom strings - on the same level as the default enums, so not as a custom property as mentioned above).
Contact
- IDS Information Model: responsibles from Fraunhofer FIT are @JohannesLipp and @clange
- IDS Usage Control language: responsibles from Fraunhofer IESE are @Brandstaedter and @hosseinzadeha
- IDS Information Model libraries (CodeGen & Serializer): responsibles from Fraunhofer IAIS are ??
- IESE-side contact person from ODRL: @riannella
The info model models the LeftOperand of a constraint as an enum. This means that the infomodel cannot express constraints other than those defined in the enum class. For example, it is impossible to express policies that include usage constraints other than the 17 defined in the enum class.
My understanding of IDS is it supports ODRL and extensible policy constraints so this is a bug in the info model. This is currently a severe blocker for the EDC and need to reach out to the infomodel folks for help.
.cf https://gist.github.com/jimmarino/0e4b1cddc6d42bd704c13e48881797ff