bestJWSAlg should take a list of supported algorithms

[kaol]

I think bestJWSAlg should take a list of algorithms supported by the recipient as well. The key may potentially support it but there's no guarantee that the recipient will recognize it. In particular, OpenID Connect's discovery document defines fields

• request_object_signing_alg_values_supported
• id_token_signing_alg_values_supported
• userinfo_signing_alg_values_supported
• token_endpoint_auth_signing_alg_values_supported
• introspection_endpoint_auth_signing_alg_values_supported

and in my case I was using openid-connect library which uses bestJWSAlg which returns PS512 but the provider I'm using only lists RS256 and HS256 in the discovery and using PS512 got me only errors.

[frasertweedale]

Yes, that's a good idea. I will introduce a new function for this purpose, call it negotiateBestJWSAlg or something like that, and ping you when it is ready for review. I hope to find time in the next few weeks to do some work on jose.

[frasertweedale]

@kaol please take a look at the feature/118-negotiate-alg branch, which adds a negotiation function:

negotiateJWSAlg
  :: (MonadError e m, AsError e)
  => JWK
  -> Maybe (NonEmpty JWA.JWS.Alg)
  -> m JWA.JWS.Alg

Please let me know if it meets your needs, and any other feedback.

[kaol]

Yes, that looks suitable for the purpose. Thanks. For reference, here's a version of openid-connect that uses it: https://github.com/KSF-Media/openid-connect/tree/feature/negotiate-JWS-alg

I could still suggest one change about it: Remove the Maybe from the publicly exposed negotiateJWSAlg and add a third internal function that's used by both bestJWSAlg and negotiateJWSAlg. IMHO that'd be a cleaner design, unless you're thinking of deprecating best and would offer only negotiate.

[frasertweedale]

@kaol, thanks for the feedback. I will implement the API change you suggested. I have some other changes in progress but I'll aim for a new release during the Christmas break.