Hello Nicolas,
The situation you describe of nonce switching with different RSs using the
same domain is possible. But I believe in practice it's rather unlikely to
occur and is self correcting even if it does occur (though kinda
chatty/inefficient). I don't believe it's worthwhile to add stuff to the
protocol to optimize for the situation (of course, the WG should chime-in
if I'm off base from rough consensus here) . The name "iss" is rather
overloaded and would probably not be appropriate, even in the case
something was added. Also - the realm parameter
<https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#section-7.1-10.2>,
which may "be included to indicate the scope of protection" seems to me
like it could serve the purpose. And, I realize it's a bit pedantic, but
note that the discussion is about RS-provided nonce but the example shows
what would be an AS response.
With respect to "iat" and out-of-sync clocks - some leeway (on the order of
a few seconds or minutes) in both directions to accommodate reasonable and
likely clock skew is probably a good idea. As mentioned to Rohan in a prior
reply, I'll look to qualify this a bit better in the next revision of the
draft.
On Tue, Mar 22, 2022 at 8:03 PM Nicolas Mora <nico...@babelouest.org> wrote:
> Hello,
>
> I would like to add some minor comments to this draft, based on what I've
> seen so far.
>
> - Resource Server-Provided Nonce
> Since a client may have to add different nonces for different RS in the
> DPoP token, it would be useful to add the issuer in the RS error response,
> so the client can differntiate nonces more easily.
> There may be different RS using the same domain, the client might not know
> it, and therefore switch nonces again and again between the RS.
> Instead, if the RS error response looks like this, there will be no
> ambiguity:
>
> HTTP/1.1 400 Bad Request
> DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v
>
> {
> "error": "use_dpop_nonce",
> "error_description":
> "Authorization server requires nonce in DPoP proof",
> "iss": "https://resource.tld/person/";
> }
>
> - iat and not synced servers
> In addition to Rohan's question about the reasonable lifetime to expect
> for a DPoP token, I'm wondering what is reasonable to accept concerning iat
> in the future, where the client's clock may be out of sync. The paragraph
> 11.1 says "the server MAY accept DPoP proofs that carry an iat time in the
> reasonably near future". Could we add what a reasonably near future might
> be? In my implementation there is no gap allowed, so I'm wondering.
>
> /Nicolas
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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
https://www.ietf.org/mailman/listinfo/oauth
