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
