Deploying a sole Identityhub without other EDC components

[arnaugelpi]

Hi

I wanted to know if it is possible and feasible to deploy an identityhub runtime with sts embedded as a sole docker based runtime in an architecture with a custom implementation of the DSP as the connector that interacts with the participants of the dataspace.

That is without any of the usual controlplane and dataplane distributed with the EDC Connector. We would need to store credentials and VC for participants in the dataspace.

That would be necessary as the participants cannot connect to the internet by design and would rely on that central entity to handle participant's vc and did document management, similar to what this image in the mvd repository does where the "provider corp" would be a "gateway" to internal participants.

I understand that varies by each use case, but please any technical guidance or recommendations would be appreciated.

Thanks a lot!

[paullatzelsperger]

without any of the usual controlplane and dataplane distributed with the EDC Connector

IdentityHub is its very own runtime and in fact, is deployed to Kubernetes using its own Docker image. No controlplane or dataplane is included in IH. The docker image that is built in MVD is just for demo purposes, do not use it in production!

participants cannot connect to the internet by design

that sounds ... fishy. connectors that cannot communicate with other connectors are about as useful as a screen door on a submarine. They need connectivity for all DSP communication. What you seem to be after is a HTTP proxy, which the connector is not.

rely on that central entity to handle participant's vc and did document management

Yes, that is the purpose of IdentityHub. It can service multiple participants, and it is a fairly straight-forward pattern to have one IdentityHub servicing multiple participants.

The concept you mentioned, that MVD shows, is called "Management Domains", and it is something different entirely: it is basically a root catalog that contains links to other connectors which then offer a particular asset. However, each connector would still take part in DSP communication, but share the same identity (= VC and DID).

What you seem to be trying to do is to implement a "relay" connector that acts as DSP API gateway.

[arnaugelpi]

IdentityHub is its very own runtime and in fact, is deployed to Kubernetes using its own Docker image. No controlplane or dataplane is included in IH. The docker image that is built in MVD is just for demo purposes, do not use it in production!

Ok great. I knew it was somewhat possible but I wanted to clarify. Using better the IdentityHub repo to deploy using the IH related MVD extensions like the superuser-seed?

participants cannot connect to the internet by design

that sounds ... fishy. connectors that cannot communicate with other connectors are about as useful as a screen door on a submarine. They need connectivity for all DSP communication. What you seem to be after is a HTTP proxy, which the connector is not.

I misphrased that. My bad. What I meant by this is that internet connectivity can be intermittent and only possible outbound. Thus requiring some sort of DSP Gateway.

What you seem to be trying to do is to implement a "relay" connector that acts as DSP API gateway.

Yes, something like that. That DSP Gateway can delegate the protocol messages to the participants? is that something aligned with Dataspace architectures?

[paullatzelsperger]

internet connectivity can be intermittent and only possible outbound

this will not work. transient network failures should be covered by our retry mechanism, but spotty connections as you would see on a mobile phone will not. inbound connections are required as well. You would probably have to deliver DSP messages over a messaging system such as NATS or Kafka.

is that something aligned with Dataspace architectures

I cannot speak for all dataspaces, but technically you might be able to do something like that. To be clear, from the outside, all connectors (relay, all "internal" ones) would probably have to share the same identity. So from the outside, they appear as one connector/participant and the relay connector would still need to be reachable via internet.

This would be an extremely custom solution, and you'd have to replace core elements such as the DSP HTTP binding which could bring a slew of unforeseen problems.

[arnaugelpi]

Thanks a lot Paul. that is helpful.

all connectors (relay, all "internal" ones) would probably have to share the same identity. So from the outside, they appear as one connector/participant

then in this case there is still a need to create VCs for each participant, or because the relay is the only one that is not necessary?

This would be an extremely custom solution, and you'd have to replace core elements such as the DSP HTTP binding which could bring a slew of unforeseen problems.

we are exploring ways to achieve a POC with this architecture.

Thanks again.

[paullatzelsperger]

each (logical) dataspace participant needs its own VC (or set of VCs). whether each connector is also its own participant, or whether several connectors comprise one logical participant (replication) is up to you.