Switching an existing agent to using a new ledger

[swcurran]

This is a brainstorming issue -- the ideas here may or may not make sense. Please note the deficiencies and suggest improvements.

We have the use case of an existing Issuer of revocable credentials needing to change the Indy ledger from which the credentials they issue are rooted. This issue explores the use case and proposes a (hopefully simple) feature in ACA-Py to address the issue. The goal here is to minimize the impact on the controller -- minimizing the changes needed to do the transition.

For non-revocable credentials, the approach is fairly straight forward. By starting up with the agent with a new write ledger configuration and new seed (reusing the same DID on multiple Indy networks is a bad idea), new schema and cred def objects should be created on the new ledger, and the operation of the agent will remain more or less the same. Of course, this needs to be tested to verify it will work.

When revocable credentials are involved, upgrade above may also work -- although the issue of having two Indy ledgers configured for writing is unlikely to work straight off. The controller would revoke an existing credential using the RevRegId+Index and publish the revocations by CredDefId. The ACA-Py instance would see that the CredDef uses the initial DID, and when publishing send the transaction to the initial ledger, presumably with the help of the appropriate Endorser for the initial ledger.

Such an update would lead to (more or less) being able to write to multiple ledgers from a single ACA-Py instance. That might be too big a lift -- although it does have merit in the long run. An evaluation would be needed of the effort to implement that cleanly.

An alternative architecture might be the following:

• At the time of switching the ledger, make a copy of the existing ACA-Py database, and start a new instance ("Revoker") using the copy, configured to write to the old ledger using the old seed. It's only job is to publish revocations to the old ledger, so its controller is very simple, and can be operated completely independent of the actual Issuer controller.
• In the Issuer instance, a new ACA-Py feature would be activated that recognizes revocations (needed?) and publications to "old CredDefs", and quietly emits the requested actions WITHOUT sending them to the ledger. "Emits" might be to simply write the publication requests to a file, or might be to invoke a webhook to send the requests to defined endpoint -- in our case, the Revoker controller. Writing to a file might be a little safer as it would essentially eliminate the error handling needed if the Revoker Controller were unavailable during an update.
• The Revoker would receive the "publish" request (either via the webhook or by periodically loading the file), and carry out the necessary work to publish the revocations.
• Once all the issued credentials rooted to the old ledger have been revoked, the Revoker agent can be permanently shutdown.
  • It might be useful to add an endpoint to ACA-Py "Revoke all Credentials" for a given CredDef that would revoke all of the remaining unrevoked credentials. That would have to be used with care as the Issuer would not know that all the credentials have been revoked.

[WadeBarnes]

Currently, an ACA-Py instance can only be configured with a single SEED/DID. If you change the SEED/DID of an instance after it has established its secure storage it detects the difference and will not initialize properly.