But so the round trip we're saving is the call to the refresh entrypoint which would give a failure and require a new authentication, you just want to go straight to the authentication. Yeah, returning an "auth failed" instead of token expired" would solve that, is it truly worth it?
> -----Original Message----- > From: Paul Walker [mailto:catch-...@paulwalker.tv] > Sent: Friday, January 07, 2011 9:46 PM > To: William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > > Absolutely. I am not suggesting making specific error parameter values > for those scenarios. But there are scenarios in which a valid and > validated client can benefit from a more specific error value. > > if response is expired token > refresh token > else /* token has been revoked */ > initiate authorization > ... > > vs > > if token is invalid > if not able to refresh token /* let's give it a shot even if the > end user revoked me */ > initiate authorization > ... > > > On Jan 7, 2011, at 8:31 PM, William Mills wrote: > > > 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:catch-...@paulwalker.tv] > >> 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: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
