I just re-read draft 16 on this memorial day weekend :) 1. I had a comment on the suggested use of the authorization code flow for native clients [1].
Section 10.9 on auth code transmission [2] suggests users of the auth code flow should implement tls on it's redirect uri. This makes sense for web servers which may register something like "https://foo.com/i/got/authed"; but may not be possible on native clients. It's a common practice for android clients, for instance, to open a browser window to authorize a user via `Intent` and then register their redirect_uri to be a custom scheme registered with their android `activity`, something like "myapp://i/got/authed". 2. With regards to resource owner creds flow security consideration mentioned [3], it really feels like this is dodging the whole idea of oauth asking for authorization on the site owning the resources. Is this mainly meant for `official` apps developed by the site owning the resource? Otherwise, it feels like its no different than ye old basic http auth and gimme your login and password and trust me not to store them. [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.9 [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 -Doug Tangren http://lessis.me
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
