ContractAgreementMessage: Assigner and Assignee properties

[matgnt]

It seems the example for the ContractAgreementMessage here
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/message/contract-agreement-message.json
Referenced in both, the base protocol and the http binding is missing the relevant properties that differentiate it from a policy / offer object, namely: assigner and asignee
https://www.w3.org/TR/odrl-model/#policy-agreement

It also shows permission as an object which should be a list of such objects.

I'm also not sure if understand this correctly, that each and every of such objects in the list would need to contain assigner and assignee. I wonder if or why this can't be done in a similar manner as we do it in the catalog with an "enclosing context"

Updated version of the ContractAgreementMessage

I've added the fields according to https://www.w3.org/TR/odrl-model/#policy-agreement
that need to be there as far as I understood

{
    "@context":  "https://w3id.org/dspace/v0.8/context.json",
    "@type": "dspace:ContractAgreementMessage",
    "dspace:processId": "urn:uuid:a343fcbf-99fc-4ce8-8e9b-148c97605aab",
    "dspace:agreement": {
      "@type": "odrl:Agreement",
      "@id": "e8dc8655-44c2-46ef-b701-4cffdc2faa44",
      "odrl:permission": [
        {
            "target": "",
            "assigner": "",
            "assignee": "",
            "action": ""
        }
      ]
    }
  }

why not?

{
    "@context":  "https://w3id.org/dspace/v0.8/context.json",
    "@type": "dspace:ContractAgreementMessage",
    "dspace:processId": "urn:uuid:a343fcbf-99fc-4ce8-8e9b-148c97605aab",
    "dspace:agreement": {
      "@type": "odrl:Agreement",
      "@id": "e8dc8655-44c2-46ef-b701-4cffdc2faa44",
      "assigner": "", // <---------------------- changes here
      "assignee": "", // <---------------------- changes here
      "odrl:permission": [
        {
            "target": "",
            "action": ""
        }
      ]
    }
  }

It doesn't look like a big change, but now I could eliminate the redundant information about assigner and assignee from each object in the list of permissions. It further allows references to such objects as proposed in #77

Any thoughts?

---

Matthias Binzer
Robert Bosch GmbH

[jimmarino]

I think this brings up two issues:

1. One that I need to fill out in Handling Participant Ids in the Contract Agreement #92, which is two fields identifying the participants (not participant agents, a subtle difference). These properties should be under the dspace namespace and use the "consumer" and "provider" terminology.

2. We may want to profile ODRL to not allow assigned and assignee properties similar to the way we disallow the target property. @sebbader what do you think about this?

Thoughts?

[matgnt]

Closing the issue, since the topic has been discussed and resolved in #195