Skip to main content

Last Call Review of draft-ietf-oauth-browser-based-apps-22
review-ietf-oauth-browser-based-apps-22-artart-lc-blanchet-2025-02-03-00

Request Review of draft-ietf-oauth-browser-based-apps
Requested revision No specific revision (document currently at 26)
Type IETF Last Call Review
Team ART Area Review Team (artart)
Deadline 2025-02-04
Requested 2025-01-21
Requested by Deb Cooley
Authors Aaron Parecki , Philippe De Ryck , David Waite
I-D last updated 2025-12-04 (Latest revision 2025-12-03)
Completed reviews Secdir IETF Last Call review of -14 by Watson Ladd (diff)
Genart IETF Last Call review of -22 by Thomas Fossati (diff)
Artart IETF Last Call review of -22 by Marc Blanchet (diff)
Opsdir IETF Last Call review of -22 by Qin Wu (diff)
Secdir IETF Last Call review of -22 by Watson Ladd (diff)
Httpdir IETF Last Call review of -22 by Martin Thomson (diff)
Rtgdir IETF Last Call review of -22 by Matthew Bocci (diff)
Assignment Reviewer Marc Blanchet
State Completed
Request IETF Last Call review on draft-ietf-oauth-browser-based-apps by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/5vic_RaeGJ2tONzJuu3Iy8EG-z0
Reviewed revision 22 (document currently at 26)
Result Ready w/nits
Completed 2025-02-03
review-ietf-oauth-browser-based-apps-22-artart-lc-blanchet-2025-02-03-00
I've reviewed this document as an assigned ART reviewer. I'm not an expert in
Oauth. I haven't seen any issue from the perspective of ART or i18n. I found
this document comprehensive and detailed and useful for application architects
and developers.

I have the following comments.

Substantive:
- On my reading, it seems that the only foundation threat here is the ability
for the attacker to inject malicious code. Okay. If this is the case, I think
this should be pointed out clearly at the beginning of the document. - On my
reading, I see that this document discusses two topics: security issues and
best practices for browser based apps that are using any kind of authentication
mechanism and specific ones when using Oauth. I'm wondering if a) we already
have any document that already describes the generic issues, in which case, we
should refer or update;  b) if we don't have, given that a lot of this document
is valuable for issues not specifically related to Oauth, that we could split
the document in two: one for non-Oauth issues and then having the second one
strictly on Oauth specific issues. That way, the first one can be referenced by
non-Oauth work. Having said that, that suggestion may have been discussed
already in the working group or may not make sense for reasons I don't know.
Please discard if it does not make sense.

Editorial:
- Section 4. expand PKCE on first use and add reference. That expansion is done
later in document in section 6.3.2.1, so then remove that expansion there. -
DPoP similarly