request object should contain iat or nbf

Issue #177 closed
Joseph Heenan created an issue

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 (6)

  1. Joseph Heenan 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.

  2. 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.

  3. 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>>

  4. Log in to comment