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
