I caught up on the thread and with Luke yesterday afternoon and am fine with the user-agent flow using the fragment in the token and code case.
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton <bea...@google.com> wrote: > I can't parse this diagam, but here's my take: > > - web server flow should always return just a code. > parameter always goes in the query string > it would be sort of reasonable to have the code exchange return > just an access token, instead of a refresh token and an access token. > Or a refresh token with a shorter lifetime than indefinite. > > - user-agent flow can reasonably return either just a token, or a > token and a code > both parameters always go in the fragment, to avoid busting the browser > cache > same comments about lifetime of refresh tokens... > > Cheers, > Brian > > On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > Please answer this based on actual use cases. When returning parameters > > using the redirection URI call, which of these combinations make sense? > > > > | Code | Token | Code & Token > > ---------+------+-------+-------------- > > Fragment | a | 1 | 3 > > Query | 2 | b | c > > Split* | n/a | n/a | d > > > > * token in fragment, code in query > > > > Known use cases: > > > > 1 - current user-agent flow > > 2 - current web-server flow > > 3 - as described by Brian and Naitik > > > > Do you need any of these? > > > > a - > > b - > > c - > > d - current -10 code-and-token proposal > > > > EHL > > > > _______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
