Followup questions from draft 16 1. On storing user password for the resource owner creds flow. If the client stores a access token along with the refresh token [1] to refresh it, there should be no need to store the users password as mentioned here [2] right?
2. What value does adding the client password to a basic auth encoded header with duplicated client_id info add? [3] 3. Is the mentioned error returned to the client on token expiration supposed to result in a 401 status? Is invalid_token_error the error identifier? I don't see that in any of the error name registries. 4. "Request and response parameters MUST NOT repeat more than once, unless noted otherwise."[5] Why let them be repeated at all? That requires the server to do extra work ensuring that anything repeated contains the consistent and identical values. 5. Utf8 denotation. [6] I noticed that the owner creds flow specifies utf8 encoding. Is there an implicit assumption that all other parameters in the protocol are also utf8 encoded or were they special cased because they are foreign data flowed into the protocol not created by the server? 6. Native modified usage of the auth code flow - "Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access" [7] The issue was brought up earlier that clients the implicit flow should not be issued a refresh token because there'd be no way for the server to identify the client without the client secret. Here its suggested they do just that. Does this mean there may be a step added in the implicit flow in the future that will enable the client to refresh their access token without involving the user if the user has already chosen to authorize the app? Those are some of the things that jump out at me. I'll read if a few more times so see if anything else comes up. I'm happy to see this is all coming together! This is great work. [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.3 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 [4]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-1.5 [5]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.2 [6]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.2 [7]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 -Doug Tangren http://lessis.me
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
