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 protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
