- From: mike amundsen <mamund@yahoo.com>
- Date: Sun, 30 Oct 2011 17:59:42 -0400
- To: bergi <bergi@axolotlfarm.org>
- Cc: foaf-protocols@lists.foaf-project.org, public-rww@w3.org, WebID XG <public-xg-webid@w3.org>
The idea of advertising support for one or more auth schemes is much needed and, IMO, under-utilized right now. HTTP already has a mechanism in place for supporting new authentication schemes and for indicating preferences. Check out the WWW-Authenticate header[1] for details on how servers can list various supported schemes and how clients can id and select them. There is also an I-D[2] underway to create a public registry for new HTTP auth schemes. Finally, you might be interested in a recent I-D[3] that is trying to make it easy for clients and servers to support new auth schemes. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47 [2] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02 [3] http://tools.ietf.org/html/draft-oiwa-http-auth-extension-00 mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Sun, Oct 30, 2011 at 17:38, bergi <bergi@axolotlfarm.org> 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? > > > the bergi > > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols >
Received on Sunday, 30 October 2011 22:00:20 UTC