Absolutely. I am not suggesting making specific error parameter values for
those scenarios. But there are scenarios in which a valid and validated client
can benefit from a more specific error value.
if response is expired token
refresh token
else /* token has been revoked */
initiate authorization
...
vs
if token is invalid
if not able to refresh token /* let's give it a shot even if the end
user revoked me */
initiate authorization
...
On Jan 7, 2011, at 8:31 PM, William Mills wrote:
> All the cases like invalid format and validation errors are stuff I think you
> don't want to tell a hacker trying to muck with your tokens.
>
>> -----Original Message-----
>> From: Paul Walker [mailto:[email protected]]
>> Sent: Friday, January 07, 2011 7:42 PM
>> To: William Mills
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] expired access token : deserves unique code?
>>
>> It's superfluous if the reason is anything but the token expired. A
>> specific response code allows the client to decide not to make a
>> request when it is anything but. Otherwise, we are making the client
>> attempt a refresh that may not (from the client's perspective) succeed
>> when this information was already known by the provider and could have
>> been communicated to the client in the initial response for the
>> resource.
>>
>>
>> On Jan 7, 2011, at 7:13 PM, William Mills wrote:
>>
>>> But it's not superfluous. Their token failed, the only thing they
>> can do to fix it is refresh it.
>>>
>>>> -----Original Message-----
>>>> From: Paul Walker [mailto:[email protected]]
>>>> Sent: Friday, January 07, 2011 6:08 PM
>>>> To: William Mills
>>>> Cc: OAuth WG
>>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique code?
>>>>
>>>> I am not concerned with simplifying client development debugging as
>>>> much as the ability for clients to have the proper production logic.
>>>> The best that clients can do is always attempt a superfluous token
>>>> refresh though the reason may be do to an end user revocation for
>>>> example.
>>>>
>>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote:
>>>>
>>>>> You're giving away more information than you need to here. The
>>>> result is almost always the same, go back to the token issuer and
>> get a
>>>> new token of the type you need. I think what we're playing against
>>>> here is ease of debugging the server with your client, "Why should I
>>>> get an invalid token error with a new token?" and similar questions.
>>>>>
>>>>> I think this is something best left to implementers to put in their
>>>> own debugging, and not build it into the protocol.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email protected] [mailto:[email protected]] On
>>>> Behalf
>>>>>> Of Paul Walker
>>>>>> Sent: Friday, January 07, 2011 4:53 PM
>>>>>> To: OAuth WG
>>>>>> Subject: [OAUTH-WG] expired access token : deserves unique code?
>>>>>>
>>>>>> As far as I can tell (which isn't very far on many Friday
>>>> afternoons),
>>>>>> there is no way for a client to distinguish an expired access
>> token
>>>>>> from a revoked, malformed, etc token as the invalid_token error
>>>>>> parameter value encompasses multiple scenarios. Of course, a
>> client
>>>>>> could parse the error_description, but this is an optional
>> parameter
>>>>>> with no guaranty of a common value among providers.
>>>>>>
>>>>>> Given that the client would want to make an explicit decision to
>>>>>> request another access token using a refresh token (if available),
>>>>>> would it not benefit clients if a specific error parameter value
>> was
>>>>>> defined for this scenario?
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
