Markus Sabadello

At some point in the past, I tried to use the tools @kimdhamilton created for the DID Resolution calls (I think involving Github actions/workflows? Not sure). I remember this never...

I also agree this should be explained. And conversely, the "other effort" over at IETF should also explain that an SD-JWT/JWS can only secure the JSON document, not the underlying...

This is because the base image `gleif/keri:latest` hasn't been updated in 7 months: https://hub.docker.com/r/gleif/keri/tags

I think this sounds great. BTW there is also nothing wrong with having multiple drivers that implement the same DID method. Maybe DIDKit's support for `did:key` and `did:web` is better...

@clehner thanks for the update. I think adding support for **`onion`** would be great. You could make the address of the Tor node configurable with an environment variable, and leave...

Agree with removing the ones mentioned by @OR13 above. This seems consistent with the fact that none of those are listed at https://w3c-ccg.github.io/ld-cryptosuite-registry/ anymore.

> I see we would drop `RsaVerificationKey2018` and `RsaSignature2018` Hmm I don't think `RsaSignature2018` should be removed. If your argument is that `JsonWebSignature2020` can replace it... Well then you could...

> we might also reserve https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019 I originally added `SchnorrSecp256k1Signature2019` to the DID context in https://github.com/w3c-ccg/did-spec/pull/207. One of the arguments for reserving it, even though nobody had implemented it at...

@OR13 exactly, that's why we added BOTH `EcdsaSecp256k1VerificationKey2019` AND `SchnorrSecp256k1VerificationKey2019`.

Since `ethereumAddress` is deprecated in favor of `blockchainAccountId`, maybe that should be dropped as well. A second argument for removing `ethereumAddress` would be the discussion around brand names we had...