Deploy a viable instance of Identity Hub in a customized EDC.

[JCruiz15]

Issue

We are developing a custom connector based on the EDC technology. We have already created a successfull deployment of 2 custom connectors and have been using your postman collection to do some tests on them. However, at the time we try to include the Identity Hub, it all collapses. We are planning to deploy an IH+STS instance isolated from the connectors so the process is centralized, but this is not the example provided by the MVD repository.

We have our 2 connectors up, do the onboarding using the same code as here and tried to retrieve the catalog from one connector (that has been seeded before) to another. Then, this is the response we get from this call:

[
    {
        "message": "Unable to obtain credentials: Scope string invalid: input string was null or empty",
        "type": "BadGateway",
        "path": null,
        "invalidValue": null
    }
]

Context

We are using the latest version of EDC and its extensions (v0.11.1). And so we are for the Identity Hub. We are also using Hashicorp Vault to store our connector secrets and Postgres for persistence.

[paullatzelsperger]

First of all, IdentityHub is a decentralized identity solution, so centralizing it goes against the idea and the design of it. If your dataspace requires centralized authentication, IdentityHub might not be your best choice.

Also, embedding IdentityHub and STS in the connector - while possible - is not recommended, because in most real-world scenarios, scaling and isolation requirements differ enough for them to be separate.

That said, and for the sake of argument, I am honestly at a loss as to what you want us to say or do: The client credentials cannot be obtained because the scope string is null or empty. The error says is plainly. A quick grep on the code base would reveal that this happens in the IdentityAndTrustService on the consumer side, when creating the Self-Issued ID token using STS.

Scopes are derived from policy constraints that target a verifiable credential and are used to create an access token to IdentityHub. Numerous examples of this exist in MVD. Please familiarize yourself with DCP and DSP to understand the correlation between Policies, Scopes and VerifiableCredentials.

[JCruiz15]

Regarding the centralized IH, we are following one of the deployment scenarios provided in the documentation ("Organizational Component"). If this approach is not recommended, please let us know so we can adjust our current implementation accordingly.

As for the scopes, we're using the identityhub-with-sts-bom BOM from the EDC repository. Our goal is to keep things as simple as possible to better understand the setup.
Ideally, we just need one or two connectors and one Identity Hub instance for the whole organization. However, after following the steps I mentioned earlier, we've run into this scopes error.

[paullatzelsperger]

Just to avoid any misunderstanding: IdentityHubs can be shared among multiple connectors of the same organisation, but it should not be shared between multiple organisations. The latter case would constitute a centralized (= org-spanning) authentication system.

In the earlier case there are again two distinctions:

1. all connectors of an organization share the same participant ID: this is what we call management domains. This implies that all connectors also share the same set of credentials, and appear as single entity to the dataspace
2. each connector of an organization has its own participant ID: in this case, if you are using one single IdentityHub, it runs in "multi-tenant" mode. Each connector has its own set of credentials, keys,... Of course, each connector could also have its own IdentityHub.

I'm guessing the scope error comes from an improper policy expression, or the absense of a default scope provider. For reference, check this class in MVD, which attaches a scope to every DSP request.