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
