Manage the fact that microservices are continously re-deployed but the keys/DIDs should be persistent

ForkbombEu / DIDroom_microservices

DIDroom credential issuer part of Forkbomb's SSI solution

1 stars 0 forks source link

Manage the fact that microservices are continously re-deployed but the keys/DIDs should be persistent #90

Closed andrea-dintino closed 4 months ago

andrea-dintino commented 7 months ago

Microservices are continously re-deployed (currently manually) from files generated by the dashboard.

The Microservices have an announce flow that, if no keys/DIDs are found, creates keys and registers DIDs.

We need a mechanism (manual or automatic) to allow users to redeploy updated microservices, while preserving the existing keys/DIDs.

Currently the secret keys are stored in the credential_issuer/secret.keys (the same for all the microservices)

Possible strategies:

allow the user to download only the custom built files (the .well-known files and the custom zencode/json for the flows) separately @bbtgnn
@puria what else?

puria commented 7 months ago

Move the keys out of the micro services folder I suggest ~/.didroom + do not allow to overwrite secret files (aka test existence before writing)

matteo-cristino commented 7 months ago

Thus secret keys and custom well-known will be store in a separate folder from the one containing the actual zencode. I think that a small modification on env variables and the Makefile could do the trick 🚀 If we like this I can start to work on it

puria commented 7 months ago

Thus secret keys and custom well-known will be store in a separate folder from the one containing the actual zencode. I think that a small modification on env variables and the Makefile could do the trick 🚀 If we like this I can start to work on it

It's okay! Please try to avoid logic inside the makefile, as much as you can, but put the logic into the zencode contracts within the autorun.

matteo-cristino commented 7 months ago

Yes my idea was to put all the logics in zenroom, but I'm finding some problems:

If I set FILES_DIR=~/.didroom I have no way to read the well-knowns under the public directory (This can be fixed by writing the well-known in the announce keys in the .autorun folder)
I want to divide the contract that generates the sk and the well-known, so that if sk are present I still can update the well-known if it has been changed from didroom, but it seems that I have no way to tell ncr to execute them in a certain oder, right?

matteo-cristino commented 4 months ago

Superseeded by #127