Re: Applicability of new status code "4xx Credentials expired"?

At the moment, the libraries which manage such things typically get a token
& send it along, then if they get a 401 *assume* that it’s expired and go
for a refresh or re-auth.  I’m trying to think of a scenario in which you
were granted a token and subsequently got a 401 that is *not* an expiry.
If you can think of such a scenario, then I’d be in favor of a new code.  -T


On Sat, Aug 10, 2013 at 10:46 PM, Jan Algermissen <
jan.algermissen@nordsc.com> wrote:

> Hi,
>
> before I dive deeper into this, I am interested in immediate reactions
> from this group.
>
> I am working on token based acess control and have the following use case
> as part of an experimental protocol I am working on:
>
> A client is given an access token with a certain live time. The client
> does not know the expiration time, but when it requests a protected
> resource with an expired token the server should tell the client in the
> response. This would trigger the client to refresh the access token.
>
> I could do this with an error_code="token-expired" parameter in a 401 but
> thinking about this, I would find sth like
>
> 4xx Credentials Expired
>
> a much better fit because the status code is AFAIU more suitable when an
> automatic action by the client is desired. The semantic is also not tied to
> the protocol I have in mind, but rather generic.
>
> I'd be interested in the resonance such a proposal would provoke. If it is
> not entirely negative I'd go ahead and draft such a new code.
>
> Jan
>