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
