Hi Brian,
Hi Denis,
The choice to use "iat" vs. "exp" was made in the summer of
last year. You can see some of the discussion from then in
https://github.com/danielfett/draft-dpop/issues/38
<https://github.com/danielfett/draft-dpop/issues/38>.
I believe it pretty well has consensus at this point and thus
unlikely to be changed.
I fear that you misread my email or read it too fast. My point
had nothing to do whether using *either *of "iat" *o**r* "exp"
in the DPoP proof JWT sent by the client.
The first sentence of my email was: "One comment on slide 5
about the /time window/". So the topic was all about how the RS
SHALL handle the "jti" claim included
in the DPoP proof JWT when using a time window.
While I do believe there are reasonable arguments that can be
made on both sides of using either of "iat" or "exp", it's
difficult (and honestly time consuming and very frustrating) to
try and have such discussions or even respond in a coherent way
when fundamental aspects of the draft are misrepresented or
misunderstood. For example, the DPoP proof JWT is created by
the client not the AS so the advantages you put forward are
nonsensical in the context of the actual workings of the draft.
Section 8.1 addresses the topic of the /time window/, but this
topic should not /only /be addressed in the "Security
Considerations" section
but in the main body of the document, since some checks MUST be
done by the RS. "Security Considerations"are intended to provide
explanations but are not intended to be normative.
Section 8.1 states:
" If an adversary is able to get hold of a DPoP proof JWT,
the adversary could replay that token at the same endpoint (the HTTP
endpoint and method are enforced via the respective claims in
the JWTs). To prevent this, servers MUST only accept DPoP proofs
for a limited time window after their "iat" time, preferably
only for a relatively brief period.
Servers SHOULD store, in the context of the request URI, the
"jti" value of each DPoP proof for the time window in which the
respective
DPoP proof JWT would be accepted and decline HTTP requests to
the same URI for which the "jti" value has been seen before. In
order
to guard against memory exhaustion attacks a server SHOULD
reject DPoP proof JWTs with unnecessarily large "jti" values or
store only
a hash thereof.
(...) ".
The previous text makes the assumption that RSs MUST only accept
DPoP proofs for a relatively brief period after their "iat" time
included
in the DPoP proof JWT. This assumption is rather restrictive. A
client might get an access token and associate it with DPoP
proof JWT that
could be used during, e.g., 12 hours. A DPoP proof JWT/ access
token JWT pair could thus be used by a client during, e.g., one
day for
several sessions with a RS.
The /time window/ is currently left at the discretion of each RS
and is supposed to be short (without stating explicitly what
"short" may mean)..
It would be possible to mandate in the JWT the inclusion of the
exp (Expiration Time) Claim. (I am _not_ advocating the
inclusion of the "exp"
claim in the DPoP proof JWT).
In this way, for a RS, the /time window /would be defined using
the "iat" claim defined in the DPoP proof JWT and the "exp"
claim defined in
the JWT.
Such a description should not be done in section 8, but in a
section earlier in the main body of the document.
This would have the following advantages:
* The RS would be able to better manage the "jti" claim
values, because it would be able to discard "jti" claim
values as soon as they are
outside the time window as defined above.
* The client would know whether a DPoP proof JWT/ access token
JWT pair is still usable, in particular using the
"expires_in" status code
returned in case of a successful response from the AS and is
thus unlikely to get a rejection of both of them because of
an unknown time
window used by a RS.
Denis
On Mon, Nov 30, 2020 at 8:45 AM Denis <denis.i...@free.fr
<mailto:denis.i...@free.fr>> wrote:
One comment on slide 5 about the /time window/.
At the bottom, on the left, it is written: "Only valid for
a limited /time window/ relative to creation time".
While the creation time is defined by "iat", the /time
window/ is currently left at the discretion of each RS.
It would be preferable to mandate the inclusion in the JWT
of the exp (Expiration Time) Claim.
In this way, the /time window /would be defined by the AS
using both the "iat" and the "exp" claims.
This would have the following advantages:
* The client will know whether a token is still usable
and is unlikely to get a rejection of the token
because of an unknown time window defined by a RS.
* The RS is able to manage better the "jti" claim values,
because it will be able to discard "jti" claim values
as soon as they are outside the time window defined by
the AS in a JWT.
Denis
All,
This is a reminder that we have an Interim meeting this
Monday, Nov 30th @ 12:00pm ET, to discuss the latest with
the *DPoP *document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/>
You can find the details of the meeting and the slides here:
https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
/CONFIDENTIALITY NOTICE: This email may contain confidential
and privileged material for the sole use of the intended
recipient(s). Any review, use, distribution or disclosure by
others is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from
your computer. Thank you./
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
