On Tue, May 25, 2010 at 1:43 PM, Murali VP <mural...@gmail.com> wrote:
> Anyway to find out 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). > You can have a single redirect_uri that does a client side redirect using JavaScript. The only catch is that this is dangerous from a security perspective - your additional redirect needs to have strict rules about the domains it can forward to - so this should be considered a power-developer technique and we need to write up best practices or better provide a JS library that has gone through review. > > > 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? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
