- From: bergi <bergi@axolotlfarm.org>
- Date: Thu, 03 Nov 2011 23:34:33 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: Dominik Tomaszuk <ddooss@wp.pl>, public-xg-webid@w3.org, fielding@gbiv.com, julian.reschke@greenbytes.de, foaf-protocols@lists.foaf-project.org, public-rww@w3.org, ietf-http-wg@w3.org, http-auth@ietf.org
Am 02.11.2011 01:59, schrieb Mark Nottingham: > > 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: > http://tools.ietf.org/html/draft-ietf-appsawg-xdash > > >>> 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 > > > 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 <https://www.ietf.org/mailman/listinfo/http-auth>. > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > Thanks! Maybe we should split this a little bit. Authentication Scheme I was thinking about this a little bit more and now I'm not sure if we should use WebID or WebID-TLS or even something else. From the terminology point of view WebID-TLS would fit better. HTTPBis, part 7, section 2.3 [1] points to a link on the IANA web site which is dead [2]. I haven't found a new URL. Somebody knows if this page has moved somewhere else? On the other hand HTTPBis, part 7, section 2.3.1 [3] says: "..thus an authentication scheme can not bind information to the TCP session over which the message was received...". But even if this is true for our case, the proposed field could and should be used by WebID and existing HTTP authentication schemes. A registered scheme could avoid name conflicts. Acceptable authentication schemes request field Just a summarization: The field Accept-Authentication tells the server which authentication scheme the clients supports. Valid values are one or multiple HTTP authentication schemes. Each value can have a quality factor which must be handled like the one for the Accept field (described in RFC2616, section 14.1 or HTTPBis, part 3 section 6.1 [4]). [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3 [2] http://www.iana.org/assignments/http-authschemes [3] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1 [4] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-17#section-6.1 the bergi
Received on Thursday, 3 November 2011 22:35:20 UTC