Open cre8 opened 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.
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
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.
Right now I can pass a signer function to request the required key on demand like this example with veramo:
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