Add algorithms and claims

[Gallimathias]

Following a rigorous implementation and debugging session, this commit fully supports missing but valid ECDSA algorithms. The exception message has also been improved to facilitate easier debugging.

Furthermore, the generated DPoP previously failed because the specification requires an 'exp' claim, making time synchronisation necessary. This is now resolved by setting 'iat' and 'exp'.

Additionally, the JWK specification mandates a 'kid', which was missing and has now been added. Another peculiarity is that some identity servers reject the DPoP if the JWK is exported without a 'kid'; this has also been corrected.

[Gallimathias]

I hope thats ok that i directl open this PR, hat a hard time debugging the hole day to find all this things that are not so easy to debug. So i patch this just in my working project and want to give it just back to you, to improve this library :)

[panva]

the specification requires an 'exp' claim

It doesn't, exp is not required and therefore should be omitted. If you want exp added the optional additional? argument is there for you to use towards that goal.

the JWK specification mandates a 'kid'

It doesn't and since these keys aren't published no kid shall be part of the jwk header parameter.

Another peculiarity is that some identity servers reject the DPoP if the JWK is exported without a 'kid'; this has also been corrected.

That's to be corrected in said servers, not here.

---

I don't mind the additional ECDSA algorithms per se but their inclusion or demand I do question since they're much slower to generate, sign with or verify which, given the nature of DPoP, is not what you want.

[Gallimathias]

Hi @panva,

Thanks for the fast answer, will Look in Detail after German Easter Holidays XD.

exp: Just a fast Look, the Identity Server we need to validate against See the requirement of the exp Claim as part of RFC 9449 Point 11.1 but yes there its nit explizit mentioned and JWT See the Claim optional your right. But i understand Others as well when they say 11.1 Brings Up the exp topic.

kid: you right RFC 7517 Point 4.5 say the member ist optional. But the validation of the Identity Server Check this. But than i Change that because there should be as well the freedom to not include that, your right

alghorithms: We make good experiences with the other alghorithms and web ist Not Out Main worlds so yeah. Thanks for mention that.

[Gallimathias]

Hi @panva,

Thanks once again for the review.

I have made some further adjustments based on your feedback. However, I would like to touch upon the exp topic again in a bit more detail (see below).

---

Regarding the kid: whilst we could perhaps debate the definition of 'published', I do completely agree with you that the kid is optional and that the DPoP RFC doesn't expand on it further. Having said that, I still feel it ought to be permissible to set it, as the JWK specification does at least provide for it as an option. Given that there is currently no other way to inject the kid prior to signing, I would prefer to keep this parameter as an optional addition.

---

As for the exp claim, I’ve been looking into it a bit more closely. I realise this could easily turn into a much deeper discussion, but here is my take:

Section 11.1 of RFC 9449 states: "To limit this, servers MUST only accept DPoP proofs for a limited time after their creation (preferably only for a relatively brief period on the order of seconds or minutes)."

RFC 9449 (Section 4.2) explicitly defines a DPoP proof as a JWT. And whilst it's true that RFC 7519 (Section 4.1.4) lists the exp claim as optional.As far as I can tell at the moment, a JWT have also the option to not expire according to the specification, so it can optionally remain valid indefinitely. To my mind, this presents a contradiction between the optionality of the claim and the strict requirement that a DPoP proof must expire.

For me, it seems logical that a JWT's expiration is handled via an exp claim, as there is no alternative expiration mechanism defined for JWTs, as far as i understand. Whilst the DPoP specification leaves the exact mechanics of 'expiring' somewhat open, I am inclined to conclude that the requirement in RFC 9449 (Section 11.1) effectively mandates the use of the exp claim from RFC 7519.

---

To give a bit of context: this PR originally stemmed from a patch I wrote for my own work, and I opened it directly hoping to give something back to the project. ^^ However, if it's more convenient for you, I am more than happy to withdraw the PR for now and open either a consolidated discussion or separate, topic-specific threads to clear this up first.

What are your thoughts on this?

[panva]

Having said that, I still feel it ought to be permissible to set it, as the JWK specification does at least provide for it as an option.

I disagree. kid has no place in DPoP, there are many JWK parameters that DPoP doesn't use and that are pointless, we don't need to bloat the API to allow setting useless header parameters, kid included.

As for the exp claim

Servers enforce DPoP JWT Proofs to either be fresh by utilizing a server indicated/provided challenge (nonce) or simply form their own window of acceptance based off of the proof's iat. There is no mechanism in DPoP that mandates the use of exp.

---

If you want to continue with a PR then please revert these changes and keep just the ES384 addition. I don't feel ES512 is of any use to anyone but there may be use for ES384 yet.

The rest is nonsensical for DPoP in both scope and requirements for conformance.