Allow also async Hasher functions

[cre8]

• I'm submitting a ...
  [ ] bug report
  [X] feature request
  [X] question about the decisions made in the repository
  [ ] question about how to use this project

Right now the hasher function has to be async which is fine in environments like NodeJS where the native crypto API provides a sync call. Unfortunately this is not the case browser based environments where the webcrypto only offers async calls for non blocking execution. Therefor I would propose to change the hasher type from only Hasher to ´Hasher | AsyncHasher`. This requires updates to the PEX library and also to the ssi-types.

Are there any reasons to stay with an only sync call beside the requirement of refactoring?

[nklomp]

See also #132 (review)

Main reason indeed is refactor work and If I remember correctly you would also have to decode the SD-JWT yourself when using async. I am not really happy about the asymmetry introduced between sync and async. Not sure if that is something which has been addressed in newer versions of the sd-jwt libs. IMO it should be solved there, instead of introducing asymmetry for the outside world. But to be honest, I haven't looked too much into the SD-JWT lib anyway, so I am currently not the best person to judge/comment ;)

[cre8]

Right now it's mentioned that you need to decode itself when you want to use an async function.

As far as I know it's not possible when you once had an async call (e.g. the hash function), to wrap it in a sync call. So we not not implement the sd-jwt lib have 100% apis, otherwise it would block the JS thread and slow down a website

[TimoGlastra]

I'm fine with updating PEX to use an async hasher as well. I just didn't want to introduce this very big breaking change to the whole API of this library. There's quite some usefulness in having some of these methods sync, and it would mean all methods in this library will become async.

That's why we decided to allow both in SD-JWT (in the lower level methods). The top-level API in our sd-jwt implementation is all async, but the lower level utility types work both sync and async.