Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-01

From: Aaron Parecki <[email-masked]>
Date: Tue, 4 Dec 2018 10:34:57 -0800

Thanks for the review, Christian! Responses inline. Changes have been made
on my GitHub version, not yet published as a new revision on ietf.org.
https://github.com/aaronpk/oauth-browser-based-apps

On Tue, Nov 27, 2018 at 1:45 AM Christian Mainka <Christian.Mainka=
[email-masked]> wrote:

> Hi Aaron,
>
> I just reviewed the latest update. Thank you for this very interesting
> guideline!
>
> Here are my thoughts:
>
> - Section 4: "For authorizing users within a browser-based application"
> I would like to know whether this guide is for JavaScript Applications
> (such as SPas), for Browser Extensions, or for both?
>

I believe code running in a browser extension has a similar threat profile
as code running in a browser, so this should apply to extensions as well.
However I would want to hear from others about whether my understanding of
this is correct, as I haven't actually implemented OAuth in a browser
extension before.

>
> - Section 5: "applicaiton" -> "application"; "an web email" -> "a web
> email"
>

Thanks, fixed.

>
> - Section 6: "and MUST use a unique value for each authorization request."
> I would prefer:
> 'The "state" parameter MUST be a unique value for each authorization
> request, which is bound to the end-user's HTTP session, and must be
> verified upon receiving it in the authorization response.'
> Otherwise, it sounds like a nonce for me.
>

I'm a little worried about saying anything about HTTP sessions, since some
apps use the state to encode the session (e.g. a JWT state value) and don't
have any HTTP session associated with it at all, effectively using the
state value to restore the session. I'll change it to this:

"and MUST use a unique value for each authorization request, and MUST
verify the returned state in the authorization response matches the
original state the app created."

>
> - Section 7.3: "If authorization servers restrict redirect URIs to a
> fixed set of absolute HTTPS URIs without wildcard domains or paths"
> Covert redirect can be used by abusing unprotected GET parameters (which
> are technically not the PATH).
> So maybe it would be better to say simply "without wildcards" or
> "without wildcard domains, paths, or querys"?
>

Thanks, I've added "query string components" to the list.

>
> - Section 7.6: "dynamic registration" -> "dynamic client registration"
>

Fixed.

>
> Best Regards
> Christian
>
> --
> Dr.-Ing. Christian Mainka
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347
> http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>