Removing legacy sov did method, create new indy plugin

[PatStLouis]

Is it time to eviscerate legacy sov from the aca-py core?

There's a few issues being blocked by the legacy code and we are looking to provide better support to the askar-anoncreds wallet type. Having indy on the same implementation level as other did methods would greatly simplify this effort and provide a more consistent behavior.

I propose to deprecate did:sov in favor of a new did:indy plugin with an anoncreds registry.

[swcurran]

Issues:

• Can we use the Indicio DID Indy Plugin? https://github.com/Indicio-tech/acapy-did-indy
• Can we map did:sov to DID Indy via a configuration that an instance can set up?
  • Need to finally kill all "unqualified" did:sov's in the same way -- with care to deal with unqualified did:peer in special places.
• Remove as much Indy dependencies out of ACA-Py
• Have to sort out startup and "public-did" configurations.
• Goal is to have did:peer within ACA-Py, but all other DID Methods are loaded via plugins.
• Look at what Credo has done to accomplish the same goal.
• Search out the "if did:sov" calls that are in the code.

Need a good plan for how to do this -- that's the first step. Goal is to have a blueprint to discuss in an in-depth call - ACA-Pug or special topic meeting.

[jamshale]

I've been thinking about this and trying to figure out how to do it the last couple days. I think it will be very beneficial for aca-py core as it will take out so much complexity of the project and keep it more like it should be, an api focused, high performance vc issuer and verifier.

credo-ts is great but it has some drawbacks that aca-py is better at. It requires build a custom api layer to implement sometimes complex library function calls. Credo itself is also becoming an extremely complicated project and node projects have there own security risks and scaling challenges. Striping out all the indy ledger complexity would make it far more easier to adopt and allow the focus to be more on the storage and performance (kanon) and security.

---

Here's how I'm planning on accomplishing this. I think all the indy and ledger related code should be removed at the same time. This includes the heavily related legacy_indy anoncreds, the endorsement protocols, indy object api endpoints and the issue and verify indy handlers. Obviously this is going to have some major challenges.

Steps:

• Remove the ledger configuration from the startup arguments and have the arguments switch to use the plugin-config option. Parse and load the configuration on plugin initialization.
• Remove all ledger logic from the application startup.
• Move ledger module to plugin and register it from plugin. Provision the ledger from the plugin based on config.
• Move the indy module to the plugin.
• Remove all ledger logic from the profile classes. Create custom profile classes in the plugin which implement the acapy profile but with the indy/ledger logic. Register them with a custom profile provider.
• Move the indy anoncreds registry and register it.
• Remove the ledger/indy logic from holder classes.
• Move the indy object api routes into the plugin.
• Move the endorsement protocols and routes.
• Monkey patch the required functions and override the issue-credential and present-proof handlers. This is likely the hardest and most brittle part.
• For v1 issue and verify plugin it will need a direct dependency with the new indy plugin and acapy_agent references changed. Hopefully other plugins aren't referencing indy or ledger stuff.
• Move the anoncreds upgrade endpoint and code to the plugin.

I'm sure there is other things I'm not aware of yet but this is what I'm currently trying to accomplish.