Thanks for the review Benjamin! Specific replies are inline below.
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.
On Fri, Jan 20, 2023 at 2:20 PM Benjamin Schwartz via Datatracker <noreply@xxxxxxxx> 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
