Thanks for the review Benjamin! Specific replies are inline below.
On Fri, Jan 20, 2023 at 2:20 PM Benjamin Schwartz via Datatracker < nore...@ietf.org> wrote: > Reviewer: Benjamin Schwartz > Review result: Ready > > This is a very mature, carefully drafted specification. > Appreciate that. Thank you. > Question: Under Dynamic Client Registration, do we need a mechanism for the > client learn the required signature algorithms? In general, there is no > discussion of how mutually acceptable signature algorithms might be > negotiated. > There is not a lot of discussion on it but a client can learn the supported signature algorithms of a an authorization server though the dpop_signing_alg_values_supported metadata parameter introduced in https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-authorization-server-metada and a protected resource can signal to the client the algorithms it supports in the WWW-Authenticate challenge https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#section-7.1-10.6 > Unlike cryptographic > nonces, it is acceptable for clients to use the same nonce multiple > times, and for the server to accept the same nonce multiple times. > > This suggests that there may be another term that is better than "nonce", > such > as "epoch", "session ID", or "tag". > I tend to agree that a term other than "nonce" might have been better. And there was indeed some discussion and disagreement about it in the WG when the mechanism was introduced. But we were unable to settle on a different/better term and ultimately the rough consensus was to use nonce. > Section 11.4: > > This grant needs to be "silent", i.e., not require interaction with > the user. > > Why? Surely an occasional user authentication refresh is not such a red > flag to > ordinary users. > Unsurprisingly there are differing opinions on that. And there is at least some use of the iframe based silent refresh mechanism out there (though it's becoming less viable with increasing restrictions on 3rd party cookies in the major browsers). But the text in Section 11.4 isn't recommending its use - it's only saying that it's one of the preconditions with that particular security consideration. -- _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
