We can add it back in, but put a note that invalid may mean expired in some cases where the server cannot tell or doesn't want to tell.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Jitesh Bhate > Sent: Saturday, January 08, 2011 7:07 AM > To: Jitesh Bhate; Paul Walker; William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > > though access token gives expiration info. that can be used when server > returns Invalid_token code to determine need to refresh token or Initiate > authorization ( but I have got requests from our many client side developers > to differentiate invalidate token vs expired token) > > Jitesh > > ________________________________________ > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of > Jitesh Bhate [jbh...@exacttarget.com] > Sent: Saturday, January 08, 2011 8:57 AM > To: Paul Walker; William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > > I agree with Paul , we ran into similar issue with invalid_token status and > have to rely on error_description to give/get exact cause of error.. > > Jitesh Bhate > > ________________________________________ > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Paul > Walker [catch-...@paulwalker.tv] > Sent: Saturday, January 08, 2011 1:08 AM > To: William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > > yes, exactly. i'm not really passionate about it, but noticed during > development as something i would want and felt kind of "stuck" in not being > able to communicate this specific condition to clients (other than to parse > the > error_description). my feeling is that it would only add value. > > On Jan 7, 2011, at 9:52 PM, William Mills wrote: > > > 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 > _______________________________________________ > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
