How to handle not-understood constraints

[DominikPinsel]

This discussion is about the expected (default) behavior, how the connector should handle not-understood Constraints.

At the time of writing not-understood constraints are ignored by the EDC connector.
For example assuming this is the Asset and ContractDefinition on data provider side.

Asset

{
  "asset": {
    "properties": {
      "asset:prop:id": "100",
      "asset:prop:description": "I've got an access constraint"
    }
  },
  "dataAddress": {
    "properties": {
      "type": "HttpProxy",
      "endpoint": "https://example.com"
    }
  }
}

ConstractDefinition

{
  "id": "100",
  "selectorExpression": {
    "criteria": [
      {
        "left": "asset:prop:id",
        "op": "=",
        "right": "100"
      }
    ]
  },
  "accessPolicy": {
    "prohibitions": [],
    "obligations": [],
    "permissions": [
      {
        "edctype": "dataspaceconnector:permission",
        "action": {
          "type": "USE"
        },
        "target": "",
        "constraints": [
          {
            "edctype": "dataspaceconnector:constraint",
            "leftExpression": {
              "edctype": "dataspaceconnector:literalexpression",
              "value": "foo"
            },
            "rightExpression": {
              "edctype": "dataspaceconnector:literalexpression",
              "value": "bar"
            },
            "operator": "EQ"
          }
        ]
      }
    ]
  },
  "contractPolicy": {
    "prohibitions": [],
    "obligations": [],
    "permissions": [
      {
        "edctype": "dataspaceconnector:permission",
        "action": {
          "type": "USE"
        },
        "target": ""
      }
    ]
  }
}

Then the offer catalog of a random consuming connector looks like this:

{
  "id": "default",
  "contractOffers": [
    {
      "id": "100:a1e7dfc7-a483-4263-bbd6-a92d571731db",
      "policy": {
        "uid": "abc05435-3aaf-491b-94cc-e85a6ed72993",
        "permissions": [],
        "prohibitions": [],
        "obligations": [],
        "extensibleProperties": {},
        "@type": {
          "@policytype": "set"
        }
      },
      "asset": {
        "properties": {
          "asset:prop:description": "I've got an access constraint",
          "asset:prop:id": "100",
        }
      },
      "provider": "urn:connector:provider",
      "consumer": "urn:connector:consumer",
    }
  ]
}

I assume are are at least two cases of constraint validation, that probably need to be handled differently.

1. Constraints that are part of the access policy
2. Constraints that are part of the contract policy

For the first case I assume nothing should be generated, if an access Constraint is not understood. Obviously the Asset is protected in some way and should not be accessible for everyone. As its better to be safe than sorry I suggest creating no offers in this case.

In the second case it is probably is ok for the connector to ignore unknown constraints, as they might describe complex usage control terms and are enforced by another system. But maybe some kind of configurable behavior is also an improvement, too.

---

In conclusion I would say the EDC should not create ContractOffers if the access policy contains a not-understood Access-Constraints.

If there are use cases/requirements for Contract-Constraints it might be necessary to change here something, too. But I would wait for these requirements before updating the code.

_{Dominik Pinsel [email protected], Daimler TSS GmbH, legal info/Impressum}

[paullatzelsperger]

First of all, a ContractOffer only has the contractPolicy, never the accessPolicy. That's by design.

Second, is it possible that the JSON excerpt for ContractDefinition is missing some data? For example, neither policy has a uid or an edctype...

Third, at this level (catalog, serializing offers), we don't do any semantic policy interpretation. The provider merely serializes the contract policy and sends it over to the consumer, therefor the term "not-understood" is wrong, because no-one is attempting to understand anything here.

The only thing iffy here is that the contractPolicy is not represented in the consumer's policy. I will investigate.

[paullatzelsperger]

No, I think you are missing the point. The aforementioned access policy is ignored, because there appears to be no scope binding for it, not because the connector doesn't "understand" it, which effectively causes the constraint to be filtered out, leaving zero constraints. Therefore, you have if essence an allow-all policy, because it does not constrain anything.

Now, if a (providing) connector cannot evaluate a policy when generating offers for particular participant agent, because the constraint is malformed etc., then no offers should be generated and an error should emitted. This would mean, that the data operator had previously entered an invalid policy, which is indeed an error.

@jimmarino is this correct (policies is really your area of focus currently)?

[DominikPinsel]

Therefore, you have if essence an allow-all policy, because it does not constrain anything.

But is this the desired behavior for a Policy of the ContractDefinition.AccessPolicy? I would assume not as it carries the danger of creation contract offers, when it's not desired. A typo in the constraint or a missing extension in the EDC and a normally restricted ContractDefinition could be accessible to everyone.

_{Dominik Pinsel [email protected], Daimler TSS GmbH, legal info/Impressum}

[jimmarino]

Unfortunately, I don't understand what the problem is. The example JSON snippets also look like they weren't generated by EDC code and contain inconsistencies.

Can someone please state the issue in a couple of sentences?

[jimmarino]

No, I think you are missing the point. The aforementioned access policy is ignored, because there appears to be no scope binding for it, not because the connector doesn't "understand" it, which effectively causes the constraint to be filtered out, leaving zero constraints. Therefore, you have if essence an allow-all policy, because it does not constrain anything.

Now, if a (providing) connector cannot evaluate a policy when generating offers for particular participant agent, because the constraint is malformed etc., then no offers should be generated and an error should emitted. This would mean, that the data operator had previously entered an invalid policy, which is indeed an error.

@jimmarino is this correct (policies is really your area of focus currently)?

I can't comment on the scope binding issue because as I mentioned in my other comment, I don't understand what the issue is. Your point about a constraint-less access policy being an "allow-all" policy is correct. Also, if a policy is not understood, you are correct that this will cause an evaluation failure. A connector can't ignore policy. If a policy cannot be evaluated at runtime, e.g. a policy that requires you to eat ice cream when viewing data, the PolicyEngine should be configured with a function keyed to that policy that evaluates to true.

[paullatzelsperger]

But is this the desired behavior for a Policy of the ContractDefinition.AccessPolicy?

Yes, because binding policy contraint types to scopes pertains to configuration, which has to be done beforehand. Failing to do that is a misconfiguration, the same way as exposing an unsecured REST endpoint to the internet. The default-allow-all is by design, because in many situations there is no action to be taken for a particular (unbound) policy.

Having deny-all by default is possible by registering a pre-validator (PolicyEngine#registerPreValidator), e.g. for the contract.negotiation scope. This is not recommended though.

Now, if there is no evaluation function registered for a particular scope, which means the policy cannot be evaluated, that would result in an error. This is a different situation, and it would most definitely NOT cause rogue contract offers to be created.