feat: enable creation of DIDs for all registered methods

[chumbert]

Here're a couple of changes leveraging the recent addition of the DIDMethods registry.
The aim is to allow agents using DID methods defined in plugin to create DIDs without implementing method-specific endpoints if not necessary.

Changes:

• Relax condition on did format for the POST /wallet/did endpoint
• Validate new DIDs parameters using DIDMethods in Askar and InMemory profiles
  validate new DIDs parameters
• Factorize some validation code

Notes:

• A lot of tests are impacted by the change, if anybody has a suggestion for a quick solution to avoid that...
• It would be nice to implement the DID derivation in each DIDMethod but this would require quite some work to be able to remove the did:sov and did:key initialization hardcoded in DIDMethods.

Signed-off-by: Clément Humbert [email protected]

[swcurran]

FYI - @andrewwhitehead @ianco @dbluhm

[ianco]

I notice there are changes to the askar and in_memory wallets but not indy?

[chumbert]

I notice there are changes to the askar and in_memory wallets but not indy?

@ianco

Correct. As far as I've seen, indy wallet implementation does not support the injection context yet. And it does not appear to be a trivial change (with a 15min investigation).

Even if we want it to be added, I would argue we should defer this to another piece of work and PR. What do you think ?

[swcurran]

I would agree that we add that this is needed for the Indy-SDK as an issue and whereever else a notification should be added. However, I think we can proceed with that limitation understood.

[ianco]

I would agree that we add that this is needed for the Indy-SDK as an issue and whereever else a notification should be added. However, I think we can proceed with that limitation understood.

OK I think on-going support for indy-sdk in aca-py is an open question right now anyways, so adding a separate issue to add this functionality to the "indy" modules in aca-py is a good approach ...

[ianco]

Overall it looks good. Two things - (1) we need some documentation somewhere (minimum would be something in the swagger docs, nice would be updates to DIDResolution.md, @swcurran thoughts?), and (2) we need to update the alice/faber demo to include this feature somewhere (I can help with this one)

[chumbert]

(1) we need some documentation somewhere (minimum would be something in the swagger docs, nice would be updates to DIDResolution.md

I added a DIDMethods.md to avoid mixing all the concepts. It refers to DIDResolution.md as a follow-up read.

(2) we need to update the alice/faber demo to include this feature somewhere (I can help with this one)

I'll gladly take pointers on how we should include the feature in the demo.

[ianco]

@chumbert the docs look good, thanks! I need to think about how to add this to the demo ...

The branch is out of date though, if you can sync it up with the main branch then we can merge

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information