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

From: Jan Algermissen <[email-masked]>
Date: Sun, 11 Aug 2013 07:46:47 +0200

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

---

From: mike amundsen <[email-masked]>
Date: Sun, 11 Aug 2013 01:57:31 -0400

why not just use the www-authenticate header to start a new session after
the credentials have expired.

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Sun, Aug 11, 2013 at 1:46 AM, Jan Algermissen <[email-masked]
> wrote:

> 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
>

---

From: Tim Bray <[email-masked]>
Date: Sat, 10 Aug 2013 22:58:06 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Aug 2013 18:52:26 +0100

On 11 August 2013 06:58, Tim Bray <[email-masked]> wrote:
> 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.

... AND the difference was worth knowing about in some automated fashion.

A lot of these cases I can imagine are related to some sort of
credential revocation.  In those cases, manual intervention (running
the login scenario again) seems OK, which gives all sorts of
application-context-specific opportunities for providing any necessary
extra information.