feat: adapt to did core spec

[mirceanis]

closes #155

added support for blockchainAccountId

This PR introduces verification capabilities for DID documents that use blockchainAccountId (with eip155)
Support for ethereumAddress is maintained for backward compatibility.

added support for proofPurpose

Verification can now be done using a proofPurpose, which filters the verificationMethod based on the entries in the respective section of the DIDDocument.

Examples:

verifyJWT( token, { proofPurpose: 'authentication', ... })
verifyJWT( token, { proofPurpose: 'assertionMethod', ... })
verifyJWT( token, { proofPurpose: 'capabilityDelegation', ... })
// ...

// legacy API for 'authentication' purpose, maintained for backward compatibility.
verifyJWT( token, { auth: true, ... })`

For backward compatibility the verifier supports legacy DID resolvers that do not return DIDResolutionResult and also DID Documents that do not list assertionMethod at all.
This support will be removed once the ecosystem is more uniform with compliance.

testing

This PR also includes some hardening of existing tests. Using expect.assertions(...) to make sure that async tests are not falsely passing and replaced some test assertions with stricter versions and some toMatchSnapshot with toEqual

[mirceanis]

@oed now I think it's ready. please take another look

[awoie]

LGTM from a spec perspective although I think verificationRelationship is more appropriate than proofPurpose.

[mirceanis]

LGTM from a spec perspective although I think verificationRelationship is more appropriate than proofPurpose.

that's true, but it is so very verbose 😅 .. I guess purpose makes even more sense to me :)

[uport-automation-bot]

🎉 This PR is included in version 5.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀