Hi Aaron, I've trimmed out the bits where your fixes look great. Overall, the draft is still in good shape. Just a few small follow-ups.
On Sun, Mar 2, 2025, at 07:14, Aaron Parecki wrote: > We've added a variation of this paragraph: > https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html#section-5 I think that you have an extra comma, but that looks good. > We added a sentence to clarify what this is meant to protect, which is > only preventing the attacker from using the application's refresh token: > https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html#section-6.3.4.2.1 The text is now: > A practical implementation pattern can use a Web Worker [WebWorker] to > isolate the refresh token, and provide the application with the access token > making requests to resource servers. This prevents an attacker from using the > application's refresh token to obtain new tokens. This all seems to hinge on a web worker being "highly isolated" (see previous paragraph), which I think is overstating it a little. It might be easier to isolate a worker, but you have to acknowledge that compromised main thread JS can install or replace workers. At best, I would say "more isolated" or "more easily isolated". > We've updated all mentions of "perfect storage" to phrases like > "...even a token storage mechanism that completely isolates the tokens > from the attacker..." Hopefully this is clearer. Indeed it is. Though I still think that "perfectly" and "completely" are a little more absolute than you can justify. None of this stuff is perfect. >> In Section 8.5, please consider de-emphasis of local storage. Browsers have >> been trying to move people off the jank-inducing API for more than a decade >> now. Anything that uses storage needs to be asynchronous, local storage >> isn't. > > I added a mention of localStorage being synchronous. That's not quite what I was angling for. Your central point is independent of technology/API. It is that if you stick a token in [a store] and you have compromised code running in the same origin anywhere, that code can access the store and get your token. So, rather than talking about specific types of stores (other than listing examples) I would trim the section down to the simpler statement. (sessionStore being somewhat ephemeral is not a useful distinction here, mostly because the idea of "session" is so vague as to be useless: many browsers restore sessions after a restart) _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
