-----Original Message----- From: Henry S. Thompson [mailto:[email protected]] Sent: Tuesday, February 07, 2012 9:31 AM To: [email protected]; [email protected]; [email protected]; [email protected]; Eran Hammer; [email protected]; [email protected] Cc: [email protected] Subject: Appsdir review of draft-ietf-oauth-v2-23
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-v2-23 Title: The OAuth 2.0 Authorization Protocol Reviewer: Henry S. Thompson Review Date: 2012-02-07 IETF Last Call Date: 2012-01-24 Summary: This draft is almost ready for publication as an Proposed Standard but has a few issues that should be fixed before publication [Note - My expertise is in the areas of markup and architecture, with only the average geek's understanding of security and cryptographic technologies. Any comments below on security issues are therefore of the nature of general audience concerns, rather than technical worries.] Major Issues: 3.1.2.1 The failure to require TLS here is worrying. At the very least I would expect a requirement that clients which do _not_ require TLS MUST provide significant user feedback calling attention to this -- by analogy, absence of a padlock does _not_ suffice. . . 2.1.2.5 In a somewhat parallel case, I would expect this section to at least explain why the SHOULD NOT is not a MUST NOT. Since in practice the distinction between trusted and untrusted 3rd-party scripting is difficult if not impossible to draw, as written the 2nd para is effectively overriden by the third. 11 It seems at best old-fashioned that the designer of a new access token type, parameter, endpoint response type or extension error has no better tool available than Google to help him/her discover whether the name they have in mind is in use already. The same is true under the proposed approach for any developer trying to determine what they can use or must support. Is there some reason that mandated URI templates, after the fashion of http://www.iana.org/assignments/media-types/text/... are not mandated for the registries, e.g. http://www.iana.org/assignments/access-token-types/bearer ? If there is a good reason, please use it to at least explicitly acknowledge and justify the basis for failing to provide a way for users and developers to use the "follow your nose" strategy [1]. If there is no good reason, please include the appropriate language to require something along the lines suggested above. If you need a model, see [2]. Minor Issues: A short summary of the changes from OAuth 1.0/RFC5849 would have been helpful, and it might still be a good idea to add one. . . 4.1 Would it be helpful to indicate that steps D&E may occur at any time after C, and may be repeated subsequently? 11.1 It might be useful to have an 11.1.2, which repeats references to the bearer and mac access token type registration drafts? Nits: Apostrophes are missing in a few places in the text ("end-user s", "OAuth s"), presumably because a non-standard character encoding was used by one of the editors. 9 The bulleted list after "When choosing between an external or embedded user-agent, developers should consider:" contains several grammatical errors, e.g. "External user-agents. . . It" and "Embedded user-agents educate end-user" . . . ht [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html [2] http://www.w3.org/2005/04/xpointer-schemes/ -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: [email protected] URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
