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