Scoping TrustedIssuerRegistry to participant context in multi-tenant deployments

[fdionisi]

Long-time EDC listener, first time caller 😄 bear with me if I'm covering ground that's already been discussed.

I'm running the virtual connector as a multi-tenant managed platform, hosting participants from different dataspaces on shared connector runtimes. While working through end-to-end data transfer tests, I hit what looks like a structural gap worth raising.

The problem

The default TrustedIssuerRegistry is a single global Map<String, Set<String>> populated at startup by TrustedIssuerConfigurationExtension from edc.iam.trusted-issuer.* config. In a single-tenant deployment this works fine. In a multi-tenant virtual connector hosting participants from different dataspaces on the same runtime, every participant context shares the same registry. The result is that Participant A ends up trusting Participant B's issuer, resulting in a trust boundary violation.

Naïve solution

participantContextId is available in DcpIdentityService.verifyJwtToken and is already threaded through DID resolution, STS token creation, and presentation requests. It stops flowing at VerifiableCredentialValidationServiceImpl.validate() and, HasValidIssuer therefore has no way to scope its registry lookup to the participant being validated.

From what I can tell, fixing this cleanly means threading participantContextId through the validation service signature so HasValidIssuer can do a participant-scoped lookup. The parameter is already sitting right there in verifyJwtToken; it just isn't passed forward.

After a quick chat with @ndr-brt, we surfaced DataspaceProfileContextRegistry as a concept I'd missed. He shared with me that, the committer group lean towards the idea of trusted issuers being owned by the dataspace profile rather than the individual participant, which makes sense. That said, looking at the current implementation, trusted issuers aren't part of DataspaceProfileContext yet, and it's not clear to me how participant-to-profile resolution would work at validation time.

Current workaround

One possible workaround I'm considering is taking advantage of the additionalRules hook in validate(), which could be used to inject a participant-scoped rule, while set the global registry to wildcard to suppress the built-in HasValidIssuer. It'd do the job, although I'd still have to replace DefaultTrustedIssuerRegistry with a custom allow-all implementation, since getSupportedTypes is keyed by issuer DID and returns empty for any unknown DID, there's no config-level way to blanket-suppress it. Does that seem like a reasonable path, or is there a cleaner way to approach this before the proper fix lands upstream?

[wolf4ood]

Hi @fdionisi

thanks for raising the discussion, my two cents here.

Having a trusted registry for a single participant i think is not needed for now, since usually the trusted issuers are per dataspace

Having a TrustedIssuerRegistry that works either globally and locally for the single participant would be a major change and not sure we actually need it for now.

The comment from @ndr-brt was right, in theory it should be a trusted issuer should be associated with one or multiple DataSpaceProfileContext. This could be done with "minor change" i think with default configuration to make it work as now.

Anyway the multi-dataspace setup of EDC is not completed yet and there is still work to do, so in case expect changes :)

For this specific case associating a trusted issuer to DataSpaceProfileContext is a valid use case and what we have to do anyway for completing the work of multi-dataspace setup in EDC.

In case we could raise an issue about this and investigate this a bit more in the next iterations.