request object should contain iat or nbf

[Joseph Heenan]

We discussed this issue once, at:

https://bitbucket.org/openid/fapi/issues/152/request-objects-should-have-iat-and-exp

The conclusion of the call was that adding exp was sufficient, and this was added for the second implementers draft. (I can't recall what the argument against requiring iat or nbf was.)

I'm not convinced the current situation is sufficient.

If we consider a mobile device that is a private client (via dynamic registration) then the end-user is in control of the current time on the device. If an attacker was to set the time forward and trigger an authorisation, they could obtain a request object that had a long validity (eg. years).

My understanding of the call was there was wide consensus that request objects should have a limited time period where they are valid.

In theory an AS could reject a token that expires a long time in the future, but I'm not convinced that would be considered compliant with the specifications.

I think requiring nbf is the only real way to mitigate the generation of request objects with long validity.

[Joseph Heenan]

Discussed on today's call.

A change is needed but wasn't felt crucial for 2nd implementers draft.

The requirement should be on nbf, as there is less required behaviour for iat.

[Nat Sakimura]

We discussed this issue once, at:

https://bitbucket.org/openid/fapi/issues/152/request-objects-should-have-iat-and-exp

The conclusion of the call was that adding exp was sufficient, and this was added for the second implementers draft. (I can't recall what the argument against requiring iat or nbf was.)

I'm not convinced the current situation is sufficient.

If we consider a mobile device that is a private client (via dynamic registration) then the end-user is in control of the current time on the device. If an attacker was to set the time forward and trigger an authorisation, they could obtain a request object that had a long validity (eg. years).

My understanding of the call was there was wide consensus that request objects should have a limited time period where they are valid.

In theory an AS could reject a token that expires a long time in the future, but I'm not convinced that would be considered compliant with the specifications.

I think requiring nbf is the only real way to mitigate the generation of request objects with long validity.

[Joseph Heenan]

pull request created to add nbf as per discussion on call; https://bitbucket.org/openid/fapi/pull-requests/111/part2-add-clause-about-nbf/diff

[Nat Sakimura]

FAPI-RW: Limit the lifetime of the request object

In cases where the attacker can control the time on the client (such as a mobile phone that is a confidental client), it is desireable to ensure that the request objects created still have a limited life time.

Add 'nbf' requirement to address this.

closes #177

→ <<cset 8b5f15381804>>