I think it depends on which profiles we end up with. If we have the web and rich client profiles from Dick's WRAP draft plus the JS profile from David's draft, I would want to return the refresh token with the first two profiles but not with the third. Since our refresh tokens are going to be very long lived in most cases (months), I'd like to promote that they are kept server-side. I don't want to return the refresh token to the client in the JS profile and have it sent to the server over HTTP or set in a cookie.
At the very least, I would like the refresh token return to be optional if it's not returned in a server-to-server or to a device that has secure storage. This brings up the question of the device profile -- there are some devices (ex. xbox) that have a way to secure the refresh token, there are others that do not. It may be good to either allow the device to self-declare (in the request, specifically ask for the refresh token) or allow the provider to optionally return the refresh token based on what they know about the device. On Wed, Apr 7, 2010 at 8:05 PM, Dick Hardt <[email protected]> wrote: > I would envision that the requests from different flows will have a > different mode value, which makes them uniquely different requests for the > AS. > > I think returning a refresh token when it can't be used will lead to > confusion for Client and AS developers. > > -- Dick > > On 2010-04-07, at 1:51 PM, Eran Hammer-Lahav wrote: > > > Right now most of the flows return the same parameters (access token, > > expiration, refresh token). A few do not return a refresh token. When we > add > > signatures, we will need to add token secret and algorithm type. > > > > I know there are good reasons why certain flows do not return a refresh > > token but instead rely on the client repeating the request. However, > there > > is a lot of value in simplicity and consistency in making every request > > return the same parameters. > > > > It will also allow specifying it one time instead of over and over again. > > > > Thoughts? > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
