Last Call Review of draft-ietf-oauth-browser-based-apps-22
review-ietf-oauth-browser-based-apps-22-opsdir-lc-wu-2025年02月01日-00

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.