openwallet-foundation / sd-jwt-js

A JavaScript implementation of the Selective Disclosure JWT (SD-JWT) spec.
https://sdjwt.js.org/
Apache License 2.0
44 stars 13 forks source link

feat: Update signer-function logic to be more dynamic #103

Open cre8 opened 8 months ago

cre8 commented 8 months ago

Right now I can pass a signer function to request the required key on demand like this example with veramo:

    const signer: Signer = async (data: string) => context.agent.keyManagerSign({ keyRef: key.kid, data })
    const sdjwt = new SDJwtInstance({
      signer,
      hasher: this.algorithms.hasher,
      saltGenerator: this.algorithms.salltGenerator,
      signAlg: alg,
  })

The problem is, that the signAlg is a static value so I am not able to use any other sign algorithm in my signer.

Suggestion

The signer will return not just the signature, but also the used signAlgorithm. This would allow a more dynamic approach We could think about using this approach also for the hasher, beside the specification of sd-jwt is limited to sha-256. But It would make this approach more generalised when we change it now for the signature

lukasjhan commented 8 months ago

Input data of signer function is Base64url(header) + '.' + Base64url(payload). The value of signAlg is put into header (e.g. {alg: "EdDSA", typ: "sd-jwt"}). So I think we can't use signer's return value to set header.

lukasjhan commented 8 months ago

My first intention was to create an sdjwtInstance and issue it after the algorithm is decided. What I think was algorithm is more reusable than claim.

However as you told, framworks provide multiple alg. I propose using optional parameters in issue, present and verify method to inject the signer and signAlg. And instance's signer and signAlg value is a default

cre8 commented 8 months ago

So we should not pass the header + payload in the signer function, but only the payload? Like you said: the type of key could be defined in when selecting the issuer -> and then the key.