[ready for PR] iat and/or exp in proof parameter

[Torsten Lodderstedt]

The current text requires the iat claim to be present in the proof of type “JWT”. How is the issuer expected to process this claim? I think the exp would be better suited as it allows the client to determine the lifetime of the proof of possession.

[Tobias Looker]

I think it makes more sense for the server to decide how long it considers a PoP valid rather than the client, thus meaning iat is a more important claim to feature in the PoP.

[Pedro Felix]

This seems similar to DPoP proof token validity (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-13#name-dpop-proof-jwts).

• The DPoP draft uses iat instead of exp.
• The DPoP draft also includes a section about the clock skew problem and how to solve it with nonces. Perhaps the OpenID4VCI should include a similar section on wallet/client clock skew and proof nonces. BTW, client clock skew is a real problem that we encountered in production scenarios, namely on mobile devices (e.g. misconfigured time zones, deliberately changed time for gaming purposes).

‌

[Daniel Fett]

In DPoP, `nonce` is optional, so iat exists as an additional security mechanism.

Here, we can defined that nonce must be used always and properly (unguessable value). With that, the same functionality provided by iat and exp can be created by managing the accepted nonce values properly, in particular, by expiring them after a short period of time. If we do that, we don’t technically need iat or exp.

[Tobias Looker]

Doesn’t having iat still help in some situations to alleviate the burden of the server having to track nonces and when they were issued? If the client includes an iat, then the server can apply a time window first around the iat and determine whether its within an accepted tolerance for the server only then will it check whether it has seen the nonce before?

[Pedro Felix]

Using a time window around iat before checking the nonce can result in rejecting proofs just because the client clock is skewed. A wallet running on a mobile device with an incorrectly configured time zone will be unable to request credentials (all created proofs will have iat out of the window acceptable by the server, unless that window is really big).
So, it seems best to rely exclusively on the mandatory nonce and not require iat or exp, as suggested by Daniel Fett.

[Tobias Looker]

This means for situations where the nonce provided in the PoP is generated by the client (rather than the server) the server MUST hold on to these nonces for ever to be confident they are not being replayed an old PoP. The window around the iat is to account for clock skew between client and server but you are correct a client entirely mis-configured wouldn’t be able to obtain a credential but is that tradeoff worse then requiring the server to hold client nonces indefinitely?

[Tobias Looker]

Even if the time window around validating the iat for the server was a day that limits how long the server has to hold the nonces valid in that period for.

[Kristina Yasuda]

SIOP 2023-04-07 Need a PR around implementation considerations for this also important to point out that a nonce in the proof JWT is issued by the server (c_nonce) :)

so iat is client/wallet’s time; nonce is server’s time

[Kristina Yasuda]

PR #535

[Kristina Yasuda]

PR merged. discussion continues in issue #1987.