W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Ross Nicoll <jrn@jrn.me.uk>
Date: Mon, 12 Aug 2013 13:23:55 +0100
Message-ID: <0fuc7a4x19on6acgf8lvolbn.1376310235978@email.android.com>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Cc: ietf-http-wg@w3.org
Hi Jan, all,

I would be inclined to leave the status code as 401, and provide details of why authentication has failed as a separate header. This may involve having a heading such as "X-WWW-Authenticate-Error: credentials-expired" if nothing else fits better (I can't think of a better fit off the top of my head). This may also be useful in cases such as problems communicating with an upstream authentication system.

I should emphasise suggestion of an X- heading is just as a temporary work-around, if the idea works well there should be consideration of making it a standard header.

Ross

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
Received on Monday, 12 August 2013 12:22:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC