MVP for client-side DPoP Header support

[Gearme]

This PR includes minimal support for clientside DPoP, namely the ability to generate DPoP headers using this crate.

Related issue: #54

[ramosbugs]

hey @Gearme, thanks for contributing this PR. Unfortunately, I won't have the bandwidth to thoroughly learn the DPoP spec and get this feature merged in the near future. The spec also seems tied to OAuth2 generally, and not specifically to OIDC and its identity-related JWT claims (i.e., DPoP's use of JWTs seems pretty unrelated, and there are other Rust libraries for working with JWTs).

I'd suggest making a separate DPoP crate that possibly depends on oauth2/openidconnect. After getting an access token using either library, clients could use the DPoP crate to get a DPoP-bound access token to use in subsequent requests to the resource server.

If there are certain OAuth2/OIDC client internals (unrelated to building or verifying JWTs) that aren't currently exposed but would make building a separate crate easier, I would be open to making some generic changes to either crate to make them easier to extend, however. In other words, building a separate crate shouldn't require duplicating large portions of these two crates.

[Gearme]

All good, that's why it's a draft. I'll look into publishing DPoP functionality in a separate crate. It would still be great to build upon existing JWT support though, and you're right - if that's to come from this crate, it would have to expose its JWT types (JsonWebToken, JsonWebTokenHeader, JsonWebTokenAlgorithm, ...) at least.

I'm also unsure about jwk JWT headers (RFC 7515 (JWS) section 4.1.3) - while optional, as a part of the JWS spec they're not specific to DPoP. I'd therefore still love for these to be supported in JsonWebTokenHeader. I've noted that its current implementation seems to have conflated ID Tokens in particular with JWTs in general, since a comment on JsonWebTokenHeader claims that jwk (and a few other headers) aren't permissible according to spec. It seems to me that that's the case exclusively for IdToken, not for JsonWebToken. I'll admit though that having to narrow the set of permitted headers for the IdToken specialization of JWTs isn't straightforward for me architecturally 😉