RFC-spec algorithm claims in header result in failures

[rudi-eero]

Great work introducing this package, thanks for making it available, looking forward to contributing to it!

We're running into an issue where third-party receivers are unable to verify the JWTs produced through the use of this extension due to it requiring the use of KMS algorithm name strings in https://github.com/amzn/nimbus-jose-jwt_aws-kms-extension/blob/main/nimbus-jose-jwt_aws-kms-extension/src/main/java/com/nimbusds/jose/aws/kms/crypto/impl/KmsAsymmetricSigningCryptoProvider.java#L89-L95

This results in a JWT header that looks like:

{
  "kid": "arn:aws:kms:us-west-2:975050201494:key/42487782-1f85-46fb-83a4-0a89c38df041",
  "typ": "JWT",
  "alg": "ECDSA_SHA_384"
}

Downstream verifiers fail because they don't recognize the alg value; they're expecting the JWS algorithm names defined in the JWS RFC spec (https://datatracker.ietf.org/doc/html/rfc7518#section-3.1).

Is there any requirement blocking an update that would enable the implementation from accepting a spec-compliant algorithm and translating that internally to KMS?

[debanshuk]

@rudi-eero , Thanks for raising this issue and the PR.

I went through the PR #15 and have added a comment to make it backward compatible. Otherwise the changes look good to me. As a follow-up, we can also add similar RFC compliance alg and enc name support for JWE.