David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Consistency across access token replies
>> Its a growing list... :-)
>>
>> If the client can ask for a refresh token, why not also let it ask
>> for a secret in each flow, and a username, and specific UI, etc. At
>
Its a growing list... :-)
If the client can ask for a refresh token, why not also let it ask for a
secret in each flow, and a username, and specific UI, etc. At some point we
cross a line and the protocol becomes complex (even if rich). I'm asking
where that line is, and if this qualifies as wo
On Fri, Apr 9, 2010 at 1:01 AM, Eran Hammer-Lahav wrote:
> On 4/8/10 4:25 PM, "Marius Scurtescu" wrote:
>
>> On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav
>> wrote:
>>> This seems reasonable, but it does add more complexity for the client.
>>
>> True, but not that much. Just an extra reques
On 4/8/10 4:25 PM, "Marius Scurtescu" wrote:
> On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav wrote:
>> This seems reasonable, but it does add more complexity for the client.
>
> True, but not that much. Just an extra request parameter if it wants a
> refresh token. Default could be "no".
On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav wrote:
> This seems reasonable, but it does add more complexity for the client.
True, but not that much. Just an extra request parameter if it wants a
refresh token. Default could be "no".
> The
> thing is, there is no point in a refresh token i
This seems reasonable, but it does add more complexity for the client. The
thing is, there is no point in a refresh token if the token lifetime is the
same as the access grant. Should the server ignore the client's request in such
cases?
EHL
On 4/8/10 11:03 AM, "Marius Scurtescu" wrote:
On
Yes, I don't see a problem with returning the refresh token with every
access token response as long as its optional.
On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav wrote:
> My point is simple. *Server* should be allowed to include a refresh token
> with every access token issued. It is alrea
On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav wrote:
> My point is simple. *Server* should be allowed to include a refresh token
> with every access token issued. It is already optional everywhere it is
> included. What I suggested is to allow it to be optional everywhere.
>
> If the server d
+1, I support servers being allowed to optionally include refresh
tokens with every access token.
On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav wrote:
> My point is simple. *Server* should be allowed to include a refresh token
> with every access token issued. It is already optional everywh
My point is simple. *Server* should be allowed to include a refresh token
with every access token issued. It is already optional everywhere it is
included. What I suggested is to allow it to be optional everywhere.
If the server doesn't support refresh tokens for some flows, it should
simply not p
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
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, Era
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 inst
13 matches
Mail list logo
