Re: HTTP request header field for acceptable authentication methods

On 31/10/2011, at 8:27 PM, Dominik Tomaszuk wrote:

> On 30.10.2011 22:38, bergi wrote:
>> Currently my and maybe most other web applications with WebID support
>> have the following flow for user authentication:
>> - The user sees your web page with reduced content
>> - The user follows the login link
>> - The login resource asks for a client certificate
>> - The WebID gets bound to the session cookie
>> - The server sends a redirect to the original page
>> - Finally the user sees page with the content for that WebID
>> For example the Java address book application or most robots want to
>> access the resource in a RESTful way and will not use the described
>> flow. I haven't found a way to force the use of a client certificate if
>> the server doesn't ask for one. I propose to use a HTTP header field to
>> tell the server that the client is able to authenticate with a WebID. As
>> such a field could be also useful for other authentication methods I
>> would chose a generic name. There are already some Accept-* fields I
>> would follow that pattern. As it's currently not a standard field I
>> would prefix that field with X-.

Please, please don't do this. See:

>> Multiple values must have the same
>> format as defined for the Accept field. Also the quality parameter must
>> be handled by the server.
>> Example only with WebID authentication:
>> X-Accept-Authentication: WebID
>> Example with WebID and Basic authentication:
>> X-Accept-Authentication: WebID, Basic;q=0.9
>> What do you think about my proposal?
> It might be interesting to HTTPBis, part 7: Authentication [1] and HTTPBis Authentication Scheme Registrations [2]
> [1]
> [2]

It's not appropriate in the HTTPbis documents, as they're specifically NOT introducing new mechanisms.

Optional authentication has been widely discussed in the past; you might want to try the http-auth list <>.


Mark Nottingham

Received on Wednesday, 2 November 2011 01:00:28 UTC