Policy constraint requires ids:pipEndpoint field (rejection by Metadata Broker)

[ctoscano-eu]

A complete hierarchy of Catalog/Offer/Representation/Artifact with data usage contract is created.

We then ask the DSC ("/api/ids/resource/update") to send a ResourceUpdateMessage to a Metadata Broker (previously registered on "/api/brokers").

When the data usage policy is PROVIDE_ACCESS the DSC works as expected and the ResourceOffer is registered on the Broker.

If the data usage policy is CONNECTOR_RESTRICTED_USAGE, the DSC complain with the following error:
Received unexpected response message. [response=({reason=https://w3id.org/idsa/code/MALFORMED_MESSAGE, payload=The message could not be parsed due to an error in the message. Note that, due to being unable to parse this message, the ID of the correlating message is incorrect. Error: The following mandatory field(s) of Constraint are not filled or invalid: ids:pipEndpoint. Note that the value of "@id" fields MUST be a valid URI (e.g. emails preceded by "mailto:"). Mandatory fields are: leftOperand, operator, pipEndpoint, type=class de.fraunhofer.iais.eis.RejectionMessageImpl})]

It seems that the ids:pipEndpoint field is missing and it is mandatory on the DSC.

[tmberthold]

Hello and thank you for the feedback.

What you see there in the logs is the error message/rejection reason returned by the Metadata Broker (payload of response). DSC is not complaining about a missing ids:pipEndpoint, since this field is not supported by the DSC.

RejectionMessage returned by the Metadata Broker with following reason:
The following mandatory field(s) of Constraint are not filled or invalid: ids:pipEndpoint.
Mandatory fields are: leftOperand, operator, pipEndpoint
It looks like for the specific CONNECTOR_RESTRICTED_USAGE policy an additional field in the constraint is now required, which is not required in the other policy PROVIDE_ACCESS mentioned.

I would ask to reach out to the Metadata Broker team to see if (backward-)compatibility can be established for Connectors that do not work with a Policy Information Point and consequently cannot specify an ids:pipEndpoint. This field should ideally be Optional instead of Required for a constraint.

[SebastianOpriel]

We had this issue already several times:
International-Data-Spaces-Association/metadata-broker-open-core#90
International-Data-Spaces-Association/metadata-broker-open-core#113

I discussed around April 2022 with @sebbader that the Broker might haven gotten an updated information model, which was then no longer compatible with DSC. As I remember he fixed the issue by rolling back to an earlier stage of the used infomodel in the Broker. If I remember right, it was this commit: International-Data-Spaces-Association/metadata-broker-open-core@4f2c7f8
Maybe the infomodel got updated once again. As DSC does not implement a full XACML architecture, no PIP endpoint is available and thus can't be referenced. @sebbader also requested to make the pipEndpoint optional: International-Data-Spaces-Association/InformationModel#559

[ctoscano-eu]

Thank you for the information, now it is clear what is happening in the DSC-MetadataBroker interaction.

[tmberthold]

Will turn it as a discussion, doesn't seem to be anything we can change here without dirty workarounds.