More robust verification method selection by did

[dbluhm]

This PR is intended to supersede #3138 by adding a default verification method selection strategy for all DID methods.

This strategy relies on proof type and proof purpose to select the most appropriate verification method. For example, if proof type is Ed25519Signature2020 and purpose is assertionMethod, the changes in this PR will select the first matching method in the assertionMethod relationship that can produce a Ed25519Signature2020.

This places more expectations on the DID -- specifically that it is well formatted (which many aren't). By well formatted I mean that verification methods used for issuance are properly referenced in assertionMethod, methods used to authenticate the DID owner are in authentication, etc. In practice, this may cause challenges but it is possible for users who depend on a DID method/document that isn't well formatted to create their own strategy and plug it in. So I'm comfortable making the assertion that we can expect the DIDs we're working with to be well formatted.

This PR does adjust the interface for the VerificationKeyStrategy to better account for this. This might be painful to some plugin users who've added DID Methods by plugin and added a strategy to match. However, my hope is that those same users won't need to plug in their own strategy anymore with these changes since they should be robust enough to cover most use cases.

Shout out to @aritroCoder for his original work on #3138!

[dbluhm]

@PatStLouis please reivew (I couldn't formally request your review for some reason)

[dbluhm]

Because of the changes to the selection strategy from 3138, it's possible I haven't fully accounted for the original issue yet. I will take a closer look. I suspect we just need the prover side of the exchange to use the correct proof purpose when determining vm id.

Edit: I think I've address this now with the most recent commit.

[dbluhm]

@jamshale your input on BDD interop test failure would be appreciated. Is this an OWF migration artifact or something else?

[jamshale]

@jamshale your input on BDD interop test failure would be appreciated. Is this an OWF migration artifact or something else?

Ya. I changed a reference I shouldn't have. Should have a fix ready soon.

[PatStLouis]

@dbluhm thanks for doing this work. @aritroCoder does this cover your use case?

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[dbluhm]

I need to fix unit tests. Changes should be captured and tested at least in the json-ld scenario integration test but might be interesting/a good idea to have a more directed test of the functionality.

[swcurran]

Want to defer a merge until we get 1.1.0 release out.

[dbluhm]

Unit tests fixed; this PR is ready for final review and merge

[sonarcloud[bot]]

Quality Gate failed

Failed conditions
63.9% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud