ids-messaging: Add aditional validations

[juliapampus]

Feature Request

The ids messaging could be improved by extending the validation of incoming messages.

Which Areas Would Be Affected?

ids multipart handler

Why Is the Feature Desired?

Prevent identity theft and IDS infomodel incompatibilities.

Solution Proposal

This list could be extended:

• Compare DAT claims to message values (e.g. referringConnector == issuerConnector; check hostname of incoming request)
• Check IDS Infomodel version against inbound versions

Type of Issue

improvement

Checklist

• assigned appropriate label?
• Do NOT select a milestone or an assignee!

[sebbader]

I propose SHACL for the second task (Check IDS Infomodel version against inbound versions). The IDS IM ships with SHACL schemas (aka shapes) out of the box, and there is a pretty widely used open source library: https://github.com/TopQuadrant/shacl

[tmberthold]

For the (dat-)referringConnector == (message-)issuerConnector and hostname validation, please watch out for Catena-X, because the DAT claim is currently used for the BPN at the moment (e.g. BPNLCDQ90000X42KU as part of the referringConnector-claim URL, and the real hostname does not necessarily include that, so hostname validation will likely fail).

https://github.com/catenax-ng/product-edc/blob/1708db02372a2e85ec6e888ecbd3efeae9139b9b/edc-extensions/business-partner-validation/src/main/java/net/catenax/edc/validation/businesspartner/functions/AbstractBusinessPartnerValidation.java#L85

update: BPN seems to be now required to be part of the Connector-URL

[SebastianOpriel]

If a BPN instead of the connectors URL is used for referringConnector field, no direct interoperability with other data spaces will be possible. Or another service must be present, which allows a lookup of further details.
I ask myself how EDC in case of using BPN is able to avoid DAT reply attacks.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.