clients should be required to send a 'reasonable' exp in request object

[Joseph Heenan]

Although we currently say that servers must require an exp claim is present, there's not actually any further discussion about processing of the exp claim other than what is present in JWT, i.e. https://tools.ietf.org/html/rfc7519#section-4.1.4

It would probably be sensible to set some kind of upper limit.

e.g. for client assertions https://tools.ietf.org/html/rfc7521 says:

Note that the authorization server may reject assertions with an Expires At attribute value that is unreasonably far in the future.

This came up as we discovered an RP in the OB ecosystem was sending:

"exp": 1548068599885,

ie. Friday 5th May in the year 51026.

Some OPs seem to accept that as a valid expiry, some reject it as invalid (possibly because it's bigger than fits in a 32bit unix time_t, or possibly because they view it as too far in the future).

I'd thinking about something along the lines of "clients shall send an exp claim in the request object that has a validity of no more than 60 minutes". Even 60 minutes is perhaps unnecessarily long.

[Ralph Bragg]

This is a tad depressing that it needs to be specified to this degree. Perhaps what might be better is overarching expiries that protect both parties. i.e For FAPI Redirect API, it is only reasonable for a TPP to keep a session state active for X period.

Do we also need a section to talk about clock synchonrination / time slipage tolerances?

[Joseph Heenan]

Yeah, I think this one is basically a case of trying to stop TPPs accidentally shooting themselves in the foot (they clearly didn't intend to send an exp that far in the future), but various JWT validators do treat such a future expiry as valid I believe.

There is text in RFC7519 to allow for clock skew:

Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.

So we may not need to say anymore on that point, though it may be worth highlighting this point or making it stronger.

[Dave Tonge]

Merged in josephheenan/fapi/reasonable-exp (pull request #98)

FAPI-RW: Require request object exp to have a reasonably limited lifetime

We more explicitly limit the maximum acceptable lifetime of a request object. This should effectively stop RPs unintentionally sending request objects with very long lifetimes.

The choice of 60 minutes is fairly arbitary. It seems any value longer than 10 minutes and shorter than 24 hours likely achieves the same goal.

closes #211

Approved-by: Brian Campbell [e-mail] Approved-by: Dave Tonge [e-mail]

→ <<cset ef32d82947ab>>