With respect to the objects provided by @gtkirankumar31, the JWS object is not valid. base64url encoding
must not include padding (trailing = characters). In particular, if the signer computes the signature over the encoded payload including padding then the signature is over the wrong data. I suspect this is the case here. Whatever program created that JWS object has wrong behaviour for including the padding, and doubly wrong if the padding is included in the signing input.
A compliant implementation should reject JWS objects with invalid encoding. This is a bug in hs-jose - it should refuse to even decode the JWS, but it does tolerate the padding, and proceeds to verification (which fails). So I will try and resolve that issue, thought it is not a high priority.
With respect to the objects provided by @gtkirankumar31, the JWS object is not valid. base64url encoding must not include padding (trailing
=characters). In particular, if the signer computes the signature over the encoded payload including padding then the signature is over the wrong data. I suspect this is the case here. Whatever program created that JWS object has wrong behaviour for including the padding, and doubly wrong if the padding is included in the signing input.A compliant implementation should reject JWS objects with invalid encoding. This is a bug in hs-jose - it should refuse to even decode the JWS, but it does tolerate the padding, and proceeds to verification (which fails). So I will try and resolve that issue, thought it is not a high priority.
Originally posted by @frasertweedale in https://github.com/frasertweedale/hs-jose/issues/97#issuecomment-687654903