Dear interested IETFers, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with nit. I found this document exceptionally well written: it defines cogently the problem statement, ways to avoid the problem, and then outlines various architectures and a discussion of the benefits and precautions to be taken in each one. It makes actionable recommendations that can be understood by the broad audience that needs to read this and use oauth in browser based apps. However I am compelled to quibble with the choice of threat model and some of the statements about compromise of the client. If a client has malware that can inspect the browser, then the precautions about storage of keys etc. are irrelevant as the attacker can delete the token or block access to the TPM and force a login, then obtain the user credentials and use them to log into the server. Even the use of a Webauthn device for user login is subject to this attack, even with token binding. (Simply proxy to the device). Taking precautions to avoid the token being removed strikes me as superfluous. It does make sense to e.g. avoid history leaks or XSS or CSRF attacks, as mitigations to those do stop more limited attackers. But I'm unclear on preventing tricky attacks when an attacker with that power in the threat model wins anyway through the obvious means. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
