HTTP request header field for acceptable authentication methods

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


the bergi

Received on Sunday, 30 October 2011 21:39:36 UTC