ethr-did: Can NOT verify did:ether JWT token

I was hoping to use a key pair from one of my accounts via my web3 instance but for some reason JWT doesn’t like it.

web3 signatures are different from JWT signatures, even if the same private key is in use so it wouldn’t work with only your web3 provider.

For reference, in pseudocode web3 signatures are computed as signHash(privKey, keccak(message)) while JWT signatures are computed as signHash(privKey, sha256(message))

As a side-note, unfortunately there’s not enough bandwidth now to investigate the issues you are facing, not even to update docs for this library. PRs are still welcome, of course.

@mirceanis thanks for that information, much appreciated.

Just to be clear, the delay is needed somewhere between createSigningDelegate() and verifyJWT because createSigningDelegate() sends a transaction and that block needs to propagate to the node that responds to the calls made by verifyJWT (resolving the DID document).

So, if your flow requires some key delegation for signing but not immediately followed by verification, this delay will not be needed.

Also, perhaps it is a timing issue, see #34

you may also want to upgrade to did-jwt@0.2.0 since it fixes an issue with global Buffer

it is fixed: we need to use async await method: const { payload, issuer } = await ethrDid.verifyJWT(jwt);

you also need to register the ethr-did-resolver I see you are already importing it (const registerResolver = require('ethr-did-resolver').default). The missing step is to call registerResolver({provider : provider, registry : registry})

Also, this line seems to be unused: const keypair = EthrDID.createKeyPair() Unless you intend to sign something with that keypair, you should remove that line to avoid confusion.

Someone posted a solution in chat:

Rob helped me to find the solution and I will post here: “This can sometimes happen if you end up with multiple versions of the did-resolver package, and so ethr-did-resolver ends up being registered to the wrong copy of the root resolver. You can investigate further by running npm ls did-resolver and identify potential duplicates. Ensuring that all references are to the same version and deduped should resolve the issue — this may require updating one or more packages that depend on did-resolver.” In my case the result of npm ls did-resolver was: uport-poc@1.0.0 /Users/sofarell/workspace/uport-poc

I downgraded my "did-jwt’ to 0.0.8 and it worked fine!