Credential service and issuer service in the same runtime

[thomasrutger]

In #805 it is mentioned that running a credential service and an issuer service in the same runtime is not supported.

My interpretation of this is a runtime that includes both "identityhub-bom" and "issuerservice-bom" modules.
Why is this not supported? I currently have a runtime that does exactly this and it has been working fine so far, so I was surprised to read this.

My idea was that someone might be both a holder and an issuer at the same time, so I thought why not combine the 2 into a single runtime.

(I could still split them if they use the same underlying storage and it will probably work the same, though this will not work as well for in memory setups that I also use for testing)

[paullatzelsperger]

you may run into conflicts with the participant context IDs. To be honest, we've never really tested this, or given it much thought, because so far, we've not seen a use case for this.

It might work, but it's highly doubtful. However, if you get it to work, even better :)

[thomasrutger]

Actually, I have been running it like this for months, but so far I have not run into any issues related to this (which is why I was even more surprised to read this :) ).

I am curious why there is no use case for this. I think it might well occur that a participant could be a holder, but also an issuer (for instance for different types of credentials).

We also have a running poc environment currently being tested where the dataspace authority also happens to be a member itself (essentially issuing a membership credential to itself). Combining credential service and issuer service makes this pretty easy (of course there might be other problems with this, but for now it has to be the same party doing both things).

[paullatzelsperger]

haha, even better :)
we tend to be pretty careful with stating that something is supported or not, basically, "nothing is supported unless we verify it in a test".

I understand the use case, but having a participant be an issuer and a holder at the same time is slightly different than both features mixed in one single runtime.

Personally, I would still keep them in separate runtimes (K8S pods) because they'll have different requirements w.r.t. security, scalability, dev teams,... etc.

[thomasrutger]

I understand :).

So am I correct to conclude that a participant being both a holder and an issuer is supported, as long as they are different runtimes? Although, I do have to be careful as there might be side effects. Like I imagine both the credential service and the issuer service will both try to publish the same DID document.

I agree that having them separate in k8s is a good idea. But we also use the same runtime for local testing with in-memory stores where this is more complicated. So this saves us from having to manage an additional runtime.

[paullatzelsperger]

So am I correct to conclude that a participant being both a holder and an issuer is supported, as long as they are different runtimes?

I did not say that, I said its different :)
but good point about the DID document, this might indeed get tricky, as there would have to be one consolidated DID document, that contains both the issuer and the holder information. So, likely some finagling around the DID publisher would be required.

Like I said, we have not verified this in a test, so we can't guarantee that it works.

[thomasrutger]

Right, plus there might be other side-effects that I might not know about yet.

Anyway, thanks for clearing this up! We will continue to use our current setup (i.e. 1 runtime for issuer and credential service), as long as it keeps working for us as it has been so far.