[ready for PR] iat and/or exp in proof parameter
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.
Comments (11)
-
-
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 ofexp
. - 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).
- The DPoP draft uses
-
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 byiat
andexp
can be created by managing the acceptednonce
values properly, in particular, by expiring them after a short period of time. If we do that, we don’t technically neediat
orexp
. -
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?
-
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 haveiat
out of the window acceptable by the server, unless that window is really big).
So, it seems best to rely exclusively on the mandatorynonce
and not requireiat
orexp
, as suggested by Daniel Fett. -
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?
-
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.
-
- changed status to open
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
-
- changed title to [ready for PR] iat and/or exp in proof parameter
-
-
- changed status to resolved
PR merged. discussion continues in issue
#1987. - Log in to comment
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.