search

International-Data-Spaces-Association / ids-specification

The Dataspace Protocol is a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate Agreements, and access data in a data space
https://docs.internationaldataspaces.org/dataspace-protocol/
Apache License 2.0
30 stars 14 forks source link

ContractAgreementMessage: Assigner and Assignee properties #93

Closed matgnt closed 6 months ago

matgnt commented 1 year ago

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 commented 1 year ago

I think this brings up two issues:

  1. One that I need to fill out in #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 commented 6 months ago

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