Confusing usage of pubilcKeyJwk in the verifier interface

[TimoGlastra]

Currently when doing verification and passing the verifier according to the Verifier interface, the publicKeyJwk is optionally undefined.

I see in AFJ this is resolved by already passing the signerKey when creating the verifier (so you extract the key that the issuer should have used to sign beforehand).

But I think this can be quite confusing and may lead to people not verifying the link between the iss and the key used to sign the credential.

For supporting dids for the cnf claim I'll need to add a way to verify the link between cnf and the KB-JWT signature also, and because we can use dids we can't just extract the jwk from the cnf and the jwt header.

So I was thinking of implementing a similar interface as we have in the AFJ JWS service to add a jwkResolver. Based on some input fields, you need to return a JWK.

The input will be what is present in a JWT header + iss, or what is present in the cnf claim.

E.g. it could look something like this:

sdJwt.withJwkResolver(({ kid, iss, jwk, /* in future e.g. x5c could also be supported */ }) => {
  if (kid) {
    if (kid.startsWith('did:') {
      // resolve did to JWK

		return jwk
    }
  }

})

// or pass directly to `verify` method:
sdJwt.verify({
  jwkResolver
})
``


Thoughts on this? that way the verify method would ALWAYS get a `publicKeyJwk`, and you MUST verify that the signature is signed with a private key that matches that publicKeyJwk. I think this makes it a bit more explicit that you should verify the relation between these two

[berendsliedrecht]

Yeah I like the idea. Sounds like a good thing to add :).