- From: Dominik Tomaszuk <ddooss@wp.pl>
- Date: Mon, 31 Oct 2011 10:27:41 +0100
- To: public-xg-webid@w3.org, fielding@gbiv.com, julian.reschke@greenbytes.de
- CC: foaf-protocols@lists.foaf-project.org, public-rww@w3.org, ietf-http-wg@w3.org
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-. 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] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16 [2] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02 Best, Dominik 'domel' Tomaszuk
Received on Monday, 31 October 2011 09:28:12 UTC