- changed milestone to 3rd Implementers Draft
request object should contain iat or nbf
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.
Comments (9)
-
-
- changed status to open
-
reporter 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.
-
-
assigned issue to
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.
-
assigned issue to
-
reporter 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
-
- changed status to closed
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>>
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment