<div dir="ltr"><div dir="ltr">Do we need to relax the spec? or maybe add some non-normative guidance on how clients and servers can deal with clock skew? There are a couple of options...<input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"3","compose-window":{"secure":false}}"><div><br></div><div>1. Client posts its timestamp to a server endpoint and the server responds with an offset the client should apply to its time values to avoid clock sync issues.</div><div>2. Server returns a timestamp as part of an initial request and the client calculates an offset.</div><div>3. Others???</div><div><br></div><div>Thanks,</div><div>George</div></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Thu, May 5, 2022 at 3:03 AM dgtonge via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">New issue 496: clock sync and FAPI2 baseline<br>
<a href="https://urldefense.com/v3/__https://bitbucket.org/openid/fapi/issues/496/clock-sync-and-fapi2-baseline__;!!FrPt2g6CO4Wadw!Ih1Z3VPFyc6kowRJLyeMUUWdjAEz7grBbamDjReW9EM65ml3hHF1Q8gighyiakhcH5EJzBYHmnoO5SZ0Vnp7bYghAY9bSC3BMsiTgYTN$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://bitbucket.org/openid/fapi/issues/496/clock-sync-and-fapi2-baseline__;!!FrPt2g6CO4Wadw!Ih1Z3VPFyc6kowRJLyeMUUWdjAEz7grBbamDjReW9EM65ml3hHF1Q8gighyiakhcH5EJzBYHmnoO5SZ0Vnp7bYghAY9bSC3BMsiTgYTN$</a> <br>
<br>
Dave Tonge:<br>
<br>
We have agreed to leave the DPoP nonce in the spec, partly because of clock sync issues.<br>
<br>
However do we need to consider other parts of the spec, for example:<br>
<br>
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<br>
2. TLS certificates - there could be failures if an out of sync system clock was set past the expiry date of a valid certificate<br>
<br>
I don’t think there is much we can do about TLS certificates, but private\_key\_jwt may be an issue.<br>
<br>
Looking at [<a href="https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7523.html*(https:/*www.rfc-editor.org/rfc/rfc7523.html)__;XS8!!FrPt2g6CO4Wadw!Ih1Z3VPFyc6kowRJLyeMUUWdjAEz7grBbamDjReW9EM65ml3hHF1Q8gighyiakhcH5EJzBYHmnoO5SZ0Vnp7bYghAY9bSC3BMl43MJ6G$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7523.html*(https:/*www.rfc-editor.org/rfc/rfc7523.html)__;XS8!!FrPt2g6CO4Wadw!Ih1Z3VPFyc6kowRJLyeMUUWdjAEz7grBbamDjReW9EM65ml3hHF1Q8gighyiakhcH5EJzBYHmnoO5SZ0Vnp7bYghAY9bSC3BMl43MJ6G$</a> the relevant clauses are:<br>
<br>
```<br>
The JWT MUST contain an "exp" (expiration time) claim that<br>
limits the time window during which the JWT can be used. The<br>
authorization server MUST reject any JWT with an expiration time<br>
that has passed, subject to allowable clock skew between<br>
systems. Note that the authorization server may reject JWTs<br>
with an "exp" claim value that is unreasonably far in the<br>
future.<br>
```<br>
<br>
```<br>
The JWT MAY contain an "nbf" (not before) claim that identifies<br>
the time before which the token MUST NOT be accepted for<br>
processing.<br>
```<br>
<br>
```<br>
The JWT MAY contain an "iat" (issued at) claim that identifies<br>
the time at which the JWT was issued. Note that the<br>
authorization server may reject JWTs with an "iat" claim value<br>
that is unreasonably far in the past.<br>
```<br>
<br>
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? <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-fapi__;!!FrPt2g6CO4Wadw!Ih1Z3VPFyc6kowRJLyeMUUWdjAEz7grBbamDjReW9EM65ml3hHF1Q8gighyiakhcH5EJzBYHmnoO5SZ0Vnp7bYghAY9bSC3BMljCUD3D$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-fapi__;!!FrPt2g6CO4Wadw!Ih1Z3VPFyc6kowRJLyeMUUWdjAEz7grBbamDjReW9EM65ml3hHF1Q8gighyiakhcH5EJzBYHmnoO5SZ0Vnp7bYghAY9bSC3BMljCUD3D$</a> <br>
</blockquote></div></div>
<HR><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30"><BR>
<tr><BR>
<font color="#404040">The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.</font></td><BR>
</tr><BR>
</table><BR>