Reviewer: Qin Wu Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document focuses on providing guidelines and recommendations on how to securely implement OAuth clients in browser based applications. It is well written, I believe it is on the right track and ready for publication, however I have a few comments and suggestions as follows: Major issues: No Minor Issues: Section 9.2 said: " If the application is unable to use an API that generates a non- exportable key, the application should take measures to isolate the private key from its own execution context. The techniques for doing so are similar to using a secure token storage mechanism, as discussed in Section 8. " It looks that section 8 provides measures to isolate the private key from its own execution context. This is a good, Section 8 provide a list of secure token storage mechanism including filesystem for token storage. however it further said, Section 9.2 also said: " While a non-exportable key is protected from exfiltration from within JavaScript, exfiltration of the underlying private key from the filesystem is still a concern. " It seems that it is not recommended to store private key in the filesystem. I am wondering which other secure key storage mechanisms should be used here? is there any recommendation. Remote server for private key storage? Nits: 1. What is PKCE? Suggest to add PKCE to terminology section and provide a reference to this term. 2. Section 3 said: " Given the popularity of this scenario, this document refers to "JavaScript applications" and to "malicious JavaScript" when discussing attack patterns. " I can not parse this sentence, what is referred to "JavaScript applications" and to "malicious JavaScript"? Are you saying "JavaScript applications" and "malicious JavaScript" are equivalent? Also I suggest to add referenced section at the end of "when discussing attack patterns". 3.Section 9.4 said: " Additionally, having a single origin per application makes it easier to configure and deploy security measures such as CORS, CSP, etc. " Please expand CORS in the terminology section, also please add reference to CORS and CSP. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
