Overall I think thus is good, but I have a few comments/suggestions: I think the stateful handling of server-supplied nonces (ie the client reuses the same nonce until the server sends a new one) perhaps needs to be clarified with respect to clients making concurrent requests. Especially clients using multiple access tokens and/or DPoP keys (eg for different users). Is the nonce specific to a particular access token?
And we also need to consider a client that is itself a cluster of servers - does such a client need to synchronise nonces across instances? Does the AS/RS need to? (I can imagine this getting quite complex with different requests from different client machines hitting different AS/RS servers). I think probably any use of the DPoP-Nonce response header should also be accompanied by Cache-Control: private (or no-store) and this should be a MUST. I think we’ve also missed that the DPoP header on requests should also have Cache-Control: no-store added, at least when not sending the access token in an Authorization header. It seems slightly odd that the WWW-Authenticate challenge for RS server-supplied nonces isn’t self-contained, but I don’t see anything that says it should be so that is probably ok. (And I can see the consistency argument for using the header). It does seem a shame to pay the cost of a challenge-response roundtrip and not to do a key exchange to speed up subsequent requests, but never mind. — Neil > On 6 Oct 2021, at 17:37, Mike Jones > <[email protected]> wrote: > > > FYI, I wrote about the nonce support at https://self-issued.info/?p=2194 and > https://twitter.com/selfissued/status/1445789505902899206. > > -- Mike > > From: OAuth <[email protected]> On Behalf Of Brian Campbell > Sent: Monday, October 4, 2021 3:11 PM > To: oauth <[email protected]> > Subject: [OAUTH-WG] Fwd: New Version Notification for > draft-ietf-oauth-dpop-04.txt > > > WG, > > The collective DPoP co-authors are pleased to announce that a new -04 > revision of DPoP has been published. The doc history snippet is copied below > for quick/easy reference. The main change here is the addition of an option > for a server-provided nonce in the DPoP proof. > > -04 > * Added the option for a server-provided nonce in the DPoP proof. > * Registered the invalid_dpop_proof and use_dpop_nonce error codes. > * Removed fictitious uses of realm from the examples, as they added > no value. > * State that if the introspection response has a token_type, it has > to be DPoP. > * Mention that RFC7235 allows multiple authentication schemes in > WWW-Authenticate with a 401. > * Editorial fixes. > > > ---------- Forwarded message --------- > From: <[email protected]> > Date: Mon, Oct 4, 2021 at 4:05 PM > Subject: New Version Notification for draft-ietf-oauth-dpop-04.txt > To: ... > > > > A new version of I-D, draft-ietf-oauth-dpop-04.txt > has been successfully submitted by Brian Campbell and posted to the > IETF repository. > > Name: draft-ietf-oauth-dpop > Revision: 04 > Title: OAuth 2.0 Demonstrating Proof-of-Possession at the > Application Layer (DPoP) > Document date: 2021-10-04 > Group: oauth > Pages: 37 > URL: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > Html: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-04 > > Abstract: > This document describes a mechanism for sender-constraining OAuth 2.0 > tokens via a proof-of-possession mechanism on the application level. > This mechanism allows for the detection of replay attacks with access > and refresh tokens. > > > > > The IETF Secretariat > > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth -- Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe <https://preferences.forgerock.com/>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
