Dear Dominik,
# Reply-to set to http-auth mailing list, be careful.
I am actually interested about the idea, as I was considering similar one
for another purpose (footnote *1).
As Mark Nottingham has suggested in another reply in HTTPBIS,
it should not be X- prefixed, and it seems not to be the area of HTTPBIS working
group. HTTP-AUTH list seems to be appropriate for a moment, and
if it goes rapidly than HTTP-Auth activity, it may possibly be rerouted
to the APPSAWG.
Currently I am submitting an individual draft called
"HTTP Authentication Extensions for Interactive Clients"
<http://tools.ietf.org/html/draft-oiwa-http-auth-extension-00>, and
if you allow me I would like either to include it to the next version of this
draft, or to write a separate draft for that header.
However, there seems to be a few things to be solved before specifying:
0) the name: HTTP does not have the corresponding *-Authentication header.
Should it be either Accept-Authentication, Accept-Authorization, or
Accept-WWW-Authenticate?
1) The header will naturally take tokens for HTTP authentication schemes, which
will have registration entries in "HTTPBis Authentication Scheme Registrations"
you have mentioned, as all other "Accept-*" headers do somewhat similar.
You have included "Basic" in an example, I guessed from that.
However, as far as I know, WebID will not use HTTP Authentication layer, and
thus it will (at least naturally) not have an entry in the registry. We will
have to find the way to include non-HTTP authentication names in the headers
unambiguously, by
a) find some distinguishable syntax for holding two separate name-spaces,
b) find a way to have registration system for non-HTTP authentication,
either unified or non-conflicting to HTTP-Auth scheme tokens, or
c) find an (unlikely?) way to reserve a token in the HTTP-Auth registry.
2) Do we really need qvalue here? Or what q=0 suggests?
Do you have some opinion about these?
(*1) As far as several HTTP-Auth schemes are involved, the HTTP auth framework
allows servers to provide several possible schemes at once, and
clients to choose the most strong one. However, I want to allow
servers to check whether clients accepts my Mutual authentication scheme,
otherwise divert to Form authentication possibly for transition purpose.
On 2011/10/31 18:27, Dominik Tomaszuk wrote:
> On 30.10.2011 22:38, bergi wrote:
(skipped)
>> 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
>
--
Yutaka OIWA, Ph.D. Research Scientist
Research Center for Information Security (RCIS)
National Institute of Advanced Industrial Science and Technology (AIST)
Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]