Validating incoming payloads

[arnoweiss]

The EDC is very permissible in the payloads it accepts via the Management API. I want to outline two separate cases that create unexpected behavior.

1. "Unknown data must be a property"

Here's an invalid POST /v3/assets request (look for the "whatever"-key):

{
  "@context": {
    "edc": "https://w3id.org/edc/v0.0.1/ns/",
    "cx-common": "https://w3id.org/catenax/ontology/common#",
    "cx-taxo": "https://w3id.org/catenax/taxonomy#",
    "dct": "https://purl.org/dc/terms/"
  },
  "@id": "assetId",
  "properties": {
    "dct:type": {
      "@id": "assetType"
    },
    "cx-common:version": "assetVersion"
  },
  "privateProperties": {},
  "whatever": "data",
  "dataAddress": {
    "@type": "DataAddress",
    "type": "HttpData",
    "baseUrl": "https://myback.end/data",
    "oauth2:tokenUrl": "https://mytoken.server/token",
    "oauth2:clientSecretKey": "myTokenKey",
    "proxyQueryParams": "true",
    "proxyPath": "false",
    "proxyMethod": "true"
  }
}

For this request, the expected response would be HTTP 400, explaining that the presence of json-key "whatever" isn't known and thus rejected.

This however isn't how the API behaves. Any unknown data on the top-level of the json-hierarchy is accepted, parsed as Map<String, Object> and stored as a Property. It is therefore visible to consumers via the catalog. That poses the risk that an Admin accidentally places dataAddress- or privateProperty-data on the top level exposing sensitive information. For an ordinary REST-API a fixed JSON-schema for the Asset object with additionalAttributes: false could probably do the job.

2. "Someone might create a referenced Policy or Asset later"

As I understand, contract offers are created anew from the Contract Definitions for each Catalog-Request. That means that not only the check of the Access Policy is executed on request but also loading it. There may be reasons for it (I'm interested what those are) but the effect is the following:

Admins/Applications don't notice when they reference a non-existing Policy in a Contract Definition. This leads to very cumbersome debugging as the Data Consumer will not see the expected Data Offer in the Provider's Catalog. My intuition is that the EDC should reject the request and return HTTP 400 here as well - even though it's not a schematic but rather a logcial error.

{
  "@context": {
    "@vocab": "https://w3id.org/edc/v0.0.1/ns/"
  },
  "@type": "ContractDefinition",
  "@id": "fake-data-pass-all-offer",
  "accessPolicyId": "someBogusPolicyId",
  "contractPolicyId": "someBogusPolicyId",
  "assetsSelector": [
    {
      "@context": {
        "@vocab": "https://w3id.org/edc/v0.0.1/ns/"
      },
      "operandLeft": "https://w3id.org/catenax/ontology/common#version",
      "operator": "=",
      "operandRight": "3.0"
    }
  ]
}

The possibility that a user creates the Policy Definition after the Contract Definition is exists but appears implausible. Data providers unknowingly exposing newly created assets - just because there's a Contract Definition where the new Asset's properties match an existing assetsSelector, however, appears very plausible and poses another risk.

[ndr-brt]

1. I think this is a leftover coming from the old api, I agree that Asset properties should be defined only in the properties map.
2. Agree on this as well, policy should exist to be referenced in a contract definition.

Could you take care of creating two issues related to the points you exposed?

[arnoweiss]

We've observed another instance of unexpected behavior - this time in the consumer flow:

1. calling POST /v2/catalog/request returns a catalog including offers identified by offerIds in the form base64(contractDefinitionId):base64(assetId):base64(serverProvidedUuid).
2. triggering a negotiation via POST /v2/contractnegotiations/ referencing the offerId returned from the catalog-request workds. The negotiation finalizes.
3. If we now replace the last section of the offerId with an arbitrary base64-encoded UUID, the negotiation will still finalize. This happens despite the fact that the consumer references an offer that was never made by the provider.

Same question: Is this intended behavior?