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
