Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Policy Constraint leftOperand does not match registered functions #616

Closed
yurimssilva opened this issue Jul 14, 2023 · 5 comments · Fixed by #713
Closed

Policy Constraint leftOperand does not match registered functions #616

yurimssilva opened this issue Jul 14, 2023 · 5 comments · Fixed by #713
Assignees
Labels
bug Something isn't working

Comments

@yurimssilva
Copy link
Contributor

yurimssilva commented Jul 14, 2023

Description

The Policy Constraint leftOperand does not match the registered functions.

Consider the following Policy example:

{
  "@context": {
    "@vocab": "https://w3id.org/edc/v0.0.1/ns/"
  },
  "@type": "PolicyDefinition",
  "@id": "{{policy-id'}}",
  "policy": {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "permission": {
      "action": "use",
      "constraint": {
        "leftOperand": "Dismantler",
        "operator": "eq",
        "rightOperand": "active"
      }
    }
  }
}

The value of leftOperand will be expanded to:

{
  "http://www.w3.org/ns/odrl/2/leftOperand": [
    {
      "@id": "https://w3id.org/edc/v0.0.1/ns/Dismantler"
    }
  ]
}

Eventually, it will be deserialized to Constraint.leftOperand as "https://w3id.org/edc/v0.0.1/ns/Dismantler". However, this value does not match the registered value of "Dismantler" in the RuleBindingRegistry. As a result, the Constraint is being filtered out from the Policy.

To resolve this issue, you can take one of the following approaches:

  • Change the function keys in their registration by prefixing them with EDC's namespace, for example, "https://w3id.org/edc/v0.0.1/ns/Dismantler".
  • Expand leftOperand as a primitive @value instead of a unique instance identifier. For example:
{
  "leftOperand": {
    "@value": "Dismantler"
  }
}

It will be deserialized to Constraint.leftOperand "Dismantler", matching the function key.

The same registering pattern is followed by all the other functions, except inForceDate, which is registered with the EDC namespace prefix (https://w3id.org/edc/v0.0.1/ns/inForceDate).

Context Informations

  • Tractus-x version: 0.5.0
@yurimssilva yurimssilva added the bug Something isn't working label Jul 14, 2023
@jimmarino jimmarino self-assigned this Jul 17, 2023
@jimmarino
Copy link
Contributor

The issue appears to be "@context": "http://www.w3.org/ns/odrl.jsonld", which defines the leftOperation value as an IRI. If it is removed, the value is not expanded.

We'll look into a solution for handling this.

@jimmarino
Copy link
Contributor

Further info: if the ODRL context is added to the parent @context, the leftOperand value will be expanded usingthe EDC @vocab setting. If the policy node has @context` this will be overridden and the value expanded using the ODRL namespace.

Bottom line: we will need to explain not to do this and also deal with some of these common cases. For example, issuing a warning if certain expansions are encountered.

@yurimssilva
Copy link
Contributor Author

Also, given the way inForceDate was registered, having its own IRI in the edc vocabulary, shouldn't cx functions be registered this way as well? prefixing with cx namespace, they all would be "valid" ODRLleftOperand instances and would ease JSON-LD declaration.

@jimmarino
Copy link
Contributor

Yeah that was an oversight on my part. One solution should be we auto-register this stuff

@wolf4ood
Copy link
Contributor

I did a PR to address this in #713

Basically i've registered the functions also in the namespaced version with namespace https://w3id.org/tractusx/v0.0.1/ns/ since for example Dismantler should not be expanded as https://w3id.org/edc/v0.0.1/ns/Dismantler but more like as https://w3id.org/tractusx/v0.0.1/ns/Dismantler

So in the @yurimssilva example that would reflect in

{
  "@context": {
    "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
    "tx" : "https://w3id.org/tractusx/v0.0.1/ns/"
  },
  "@type": "PolicyDefinition",
  "@id": "{{policy-id'}}",
  "policy": {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "permission": {
      "action": "use",
      "constraint": {
        "leftOperand": "tx:Dismantler",
        "operator": "eq",
        "rightOperand": "active"
      }
    }
  }
}

wdyt?

I also did some more in this PR in order to simplify the policy creation by drafting to context. So basically users could express their policy in this way by using aliases in the contexts.

{
  "@context": [
    "https://w3id.org/edc/v0.0.1",
    "https://w3id.org/tractusx/edc/v0.0.1",
    "http://www.w3.org/ns/odrl.jsonld"
  ],
  "@type": "PolicyDefinitionRequest",
  "@id": "${POLICY_ID}",
  "policy": {
    "@type": "Set",
    "permission": [
      {
        "action": "use",
        "constraint": [
          {
            "leftOperand": "Dismantler",
            "operator": "eq",
            "rightOperand": "active"
          }
        ]
      }
    ]
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants