Closed c2bo closed 6 months ago
Thank you very much :) That's why we failed to verify jwt created other implementation. We should store the encoded value when jwt is created from encoded, just like Disclosure
My proposal would be to keep a copy of the original (base64url) JWT as a private variable when creating with fromEncode
and use that for the verify
call if it exists
My proposal would be to keep a copy of the original (base64url) JWT as a private variable when creating with
fromEncode
and use that for theverify
call if it exists
we posted at the same time :) I'll fix it right away!
@c2bo I finished the implementation. I got one question. Does the key binding JWT also signed with same public key?
@c2bo I finished the implementation. I got one question. Does the key binding JWT also signed with same public key?
KB+JWT should be signed with the key that can be found in the cnf
claim:
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
Verification right now takes a JSON Object and re-encodes this for validation (see https://github.com/openwallet-foundation-labs/sd-jwt-js/blob/d9eaf4465bb5f50f21d90549678d6c426fea0ae8/packages/core/src/kbjwt.ts#L39C1-L41C41):
This means that the original encoding of header/payload does not get preserved and signature validation might fail. A good example would be the sd-jwt-vc spec example created by the python reference implementation of sd-jwt. When debugging the calls for verification, header and payload change and signature validation fails (because the original encoding is not minified and the new encoding is minified).
Test Vectors to reproduce the problem with: