Thank you, Warren, for the review and ballot. I've replied inline below and put together this small PR with corresponding edits: https://github.com/danielfett/draft-dpop/pull/183/files
On Tue, Apr 11, 2023 at 1:10 PM Warren Kumari via Datatracker < nore...@ietf.org> wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-oauth-dpop-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for writing this; I found it a fascinating and informative read. > Appreciate that! Thanks :) > > I don't have any particularly substantive comments, but I do have some > nits and > similar to hopefully further improve the document. > > 1: "These stolen artifacts can later be used together independent of the > client > application to access protected resources." -- I found this really hard to > parse. I think that some of it is the "used together independent" > formulation - > adding a comma would help, but I think just dropping "together" works even > better (it does say "artifacts" in plural, so that's already covered?) > Indeed that is really hard to parse. I agree with dropping the word "together". 2: "Properly audience restricting access tokens can prevent such misuse" - I > think that it would be helpful to reword this, or find a reference for > "audience restricting" > That sentence caught the ire of Éric Vyncke in his review/ballot and already had one attempt at improvement by me <https://github.com/danielfett/draft-dpop/commit/010c913e41aabf695cd321245b45b9f928198832#diff-cbb16c6731a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66bR168>. But I can also add a reference, of sorts. I'm not aware of a good/easy reference for the concept of audience restricting but can point to the RFC7519 JWT `aud` claim as an example of . > > 3: Might it be worth adding a reference for XSS? I'm guessing that the > audience > will already be familiar, but if not, > https://owasp.org/www-community/attacks/xss/ ? > I feel like "cross-site scripting (XSS)" stands on its own okay and still gives an unfamiliar audience enough to search for more info. 4: Question: Why is the Nonce optional? Perhaps I missed it, but I was > unable > to find any discussion (I was expecting something in Sec 8,9 or 10) > providing > some reason why a server might not use a nonce (the closest I found was > "The > logic through which the server > makes that determination is out of scope of this document.", so I'm > guessing > that there *is* a reason, but... ) > Long story short, the reason is basically that there's complexity and extra round trip costs in using it. And there were and are differing perceptions of its value in different circumstances. The rough consensus was to leave its use (if/when/how) at the discretion of the server. -- _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
