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:catch-...@paulwalker.tv] >> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
