Multi-tenancy and participantId

[rokf]

Hello,

Let's say that one is building a multi-tenant or federated data space solution where they would like to implement the data space protocol's catalogue HTTPS binding, more specifically the catalogue request endpoint.

In this case the catalogue response could contain datasets from multiple participants (data providers), not just one. Is the idea then that such a multi-tenant connector wouldn't implement this API on a multi-tenant level but rather just have a list of the integrated connectors in the .well-known/dspace-version endpoint, one for each connector?

Alternatively it could list separate connectors in .well-known/dspace-version where the path is prefixed with the participant's ID or something like that. But then query-ing across all the participant's catalogues would require first looking at the .well-known/dspace-version content, looping over all the paths and issuing a catalogue request towards each of them 🤔

One could also rely on filters I suppose but this makes it less interoperable since filters aren't strictly defined - https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1/#catalog-request-post

Having the ability to put the data provider's participant ID into the dataset instead of the catalogue here or making the participant ID optional on the catalogue level could probably help.

Another potential solution could be that the participant ID in the context of a multi-tenant connector is a kind of unique identifier of the connector itself and not of the data provider (participant / tenant) using the connector. Would that perhaps be the intended way?

Has anyone perhaps thought about similar things already?

Thanks!

[jmcanterafonseca-iota]

Very good points here @rokf . We are implementing multitenant as well but I did not have the opportunity yet to discuss and refine on the discovery .well-known endpoint nuances with our dev team.

Regarding the participant ID in the dataset that's something we actually convey in our catalogue through the dct:publisher property allowed as per DCATv3.

Regarding the multitenant query in our case we allow the filtering of datasets by provider participant ID if needed (but not mandatory). If a query happens to return datasets from multiple participants then we return one root catalogue and then multiple nested catalogs ... as one catalog can contain other catalogs.

Unfortunately nested catalogs cannot contain a participantId and probably they should because the assumption that a single participantId is involved in a query result might not be suitable in all cases. The other option is to make participantId optional. However, as our datasets must contain publisher property, not supplying participantId in nested catalogues is not a roadblock.

Happy to continue engaging in this discussion to help evolving the spec to meet real world needs ... :)

[rokf]

I like your approach, sounds like a good way forward for us as well - it aligns with my thinking 👍

If a query happens to return datasets from multiple participants then we return one root catalogue and then multiple nested catalogs ... as one catalog can contain other catalogs.

I see - https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1/message/schema/catalog-schema.json.

What do you do with the participant ID in the root catalogue in case of a multi-tenant result then? You simply ignore it for now? It's marked as required in the JSON schema.

[jmcanterafonseca-iota]

What do you do with the participant ID in the root catalogue in case of a multi-tenant result then? You simply ignore it for now? It's marked as required in the JSON schema.

in the root catalogue we just ensure participantId is equal to dct:publisher for each dataset in rootCatalog.dataset[]