Mircea Nistor

It should be possible to re-import both identifiers and keys. This should make it easier to think about these operations as get-modify-reimport instead of thinking about changes to the database...

Also, if this is a new plugin, it should not use the `didManager` prefix for methods, to avoid collisions and confusion.

> My question would be what implications a missing `EcdsaSecp256k1VerificationKey2019` has and if VC/ VP issuance and verification work just fine with just the `EcdsaSecp256k1RecoveryMethod2020` referenced everywhere. Technically, the VerificationKey...

That's very cool! I'd suggest trying to use some of the top-level plugins instead for some operations. Your plugin depends on a DIDStore and is porting over the KMS ETH...

> Originally, I also wanted to use `didManagerImport` but ultimately couldn't do it as its args expect a `MinimalImportableIdentifier` with a keys array containing their `privatKeyHex` which I don't have...

It's possible that the implementation for this is already implemented in https://github.com/spherity/aries-rfcs-veramo-plugin If everything already works, it would be enough to just update the Awesome.md document with this

@nickz-t3 @nicobao I was also made aware of this project: https://github.com/pcibraro/veramo-bls-issuer I haven't checked it out yet, but linking it here for reference

It seems the app is defaulting to postback when not explicitly stated otherwise but because postback_url is missing, it does nothing.

> Using the python scipa library implementation and the secrets from Alice and Bob from https://identity.foundation/didcomm-messaging/spec/#appendix-a-secrets-for-test-vectors it generated the below Wonderful! I'll add it to our test suite

@veromassera There was no progress on this, but you can still add other key types using the existing resolver code. For example, adding a BLS G2 key for assertion can...