KittenBlue.JWK.from_compact/1 currently supports only limited algorithms.

It would be nice to support more algorithms like EC256, Ed25519, etc.

#15 (review)

BTW, I noticed that this line forces the HTTP client to HTTPoison. (I guess the HTTP client configuration is for Mox, though.)

It needs to make the HTTP Client response more generic.

Currently, only Payload is specified as an argument when generating JWS.

@spec sign(payload :: map, key :: KittenBlue.JWK.t()) :: {:ok, String.t()} | {:error, :invalid_key}
def sign(payload, key = %KittenBlue.JWK{}) do

It is necessary to extend to be able to specify header parameters other than alg and kid included in KittenBlue.JWK.

@spec sign(payload :: map, key :: KittenBlue.JWK.t(), other_header_params :: map) :: {:ok, String.t()} | {:error, :invalid_key}
def sign(payload, key = %KittenBlue.JWK{}, other_header_params \\ %{}) do

#8

I think we should be configurable the HTTP client by config or somewhere to inject mock module, rather than using dynamic mocking.

Currently, this library supports retrieval of public keys from Google and Apple's jwks_uri.
In the future, if this library supports other IdPs, I need to describe the contribution in the KittenBlue.JWK documentation.

Add functions to verify claims in Payload, such as iss and aud...

https://tools.ietf.org/html/rfc7519

Ref: #26 (comment)

• issue : Specify the value of alg,kid if present when calling JOSE.JWT.sign.
• verify : Create a new function that specifies a single JWK and verifies it
  • verify(token :: String.t(), key :: KittenBlue.JWK.t(), required_header :: map)

From the list of keys held by Config, make it possible to clearly specify and refer to the "Main Key" used for issuance.

This omits the following processing.

@iss_key Enum.find(@config_keys, fn kb_jwk -> kb_jwk.kid == @config_kid end)

warning: HTTPoison.request/5 defined in application :httpoison is used by the current application but the current application does not depend on :httpoison. To fix this, you must do one of:

1. If :httpoison is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

2. If :httpoison is a dependency, make sure it is listed under "def deps" in your mix.exs

3. In case you don't want to add a requirement to :httpoison, you may optionally skip this warning by adding [xref: [exclude: [HTTPoison]]] to your "def project" in mix.exs

lib/kitten_blue/jwk.ex:247: KittenBlue.JWK.fetch!/1