[Openid-specs-fapi] Issue #496: clock sync and FAPI2 baseline (openid/fapi)

[dgtonge]

New issue 496: clock sync and FAPI2 baseline
https://bitbucket.org/openid/fapi/issues/496/clock-sync-and-fapi2-baseline

Dave Tonge:

We have agreed to leave the DPoP nonce in the spec, partly because of clock sync issues.

However do we need to consider other parts of the spec, for example:

1. private\_key\_jwt - `exp` is required and `iat` is optional. A naive implementation of a client would probably set the `exp` as the current system time \+ 30 seconds. If the clock was set in the past this would cause a failure. If the clock was set in the future and `iat` was in the assertion then there would be a failure
2. TLS certificates - there could be failures if an out of sync system clock was set past the expiry date of a valid certificate

I don’t think there is much we can do about TLS certificates, but private\_key\_jwt may be an issue.

Looking at [https://www.rfc-editor.org/rfc/rfc7523.html](https://www.rfc-editor.org/rfc/rfc7523.html) the relevant clauses are:

```
The JWT MUST contain an "exp" (expiration time) claim that
limits the time window during which the JWT can be used.  The
authorization server MUST reject any JWT with an expiration time
that has passed, subject to allowable clock skew between
systems.  Note that the authorization server may reject JWTs
with an "exp" claim value that is unreasonably far in the
future.
```

```
The JWT MAY contain an "nbf" (not before) claim that identifies
the time before which the token MUST NOT be accepted for
processing.
```

```
The JWT MAY contain an "iat" (issued at) claim that identifies
the time at which the JWT was issued.  Note that the
authorization server may reject JWTs with an "iat" claim value
that is unreasonably far in the past.
```

Do we need some clause in FAPI that relaxes those processing rules if private\_key\_jwt is used in conjunction with DPoP and server nonces? 

‌

‌

‌