I wonder what the outcome was from the May 20th interim meeting, I wanted to participate but had to be at Google I/O.
3.5. User-Agent Flow 1. Since the client_id is public, the only check that prevents from any client posing as a registered client is the redirect_uri, this is fine, except that if client web application has numerous domains, each domain should register and have a separate client_id which is a pain. The alternative of a single redirect_uri returning a 302 won't work since the fragment will no more be available (I guess there are ways to get around this). 2. It is not clear from the draft how a user agent flow would refresh an access token. As per section 4, client does a HTTP(S) POST to authorization server which seems to return a 200 to user-agent if the request was successful leaving the user-agent in authorization server's domain with a JSON response data! If user-agent flow cannot refresh access token, why did it send the refresh_token in the first place in the fragment? 3. The draft doesn't seem to mention how a client in the user-agent can make protected resource requests given that such requests would be cross domain. The only viable option seems to be JSONP requests (eg. Facebook). The specification should include some material describing protected resource requests in the user-agent flow case. A relatively less important question: Since the request token has been eliminated, the web server flow (3.6) which comes close to the widely adopted OAuth 1.0's 3-legged oauth flow but without much of a dance isn't backward compatible, is this a known decision? -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
