Re: HTTP request header field for acceptable authentication methods

Hi Yutaka,

I think most people will get this email via a mailing list, so I've
trimmed the CC list a little bit.

To all others: This mail is just about a new HTTP request header field,
not about SSL or TLS. If you like to join the discussion please stay on
topic!

Am 04.11.2011 00:54, schrieb Yutaka OIWA:
> 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.

Sure, it would be cool if you could do that.

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

I would prefer Accept-Authentication. Even if there is already a field
called Authorization it's used for authentication, so we shouldn't
follow that naming scheme. Also I don't see a reason to add the WWW in
this context.

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

If we add a prefix for non-HTTP authentication schemes still a registry
is required to avoid name conflicts. If it's possible c) would be my
favorite.

> 
> 2) Do we really need qvalue here?  Or what q=0 suggests?

Maybe in combination with Basic it doesn't make sense, but a user/robot
could have multiple decentralized identities with different protocols.
The server may not support all of them, but with the qvalue the client
could tell what's the protocol of the primary id.

Example with WebID (primary) + OpenID:
Accept-Authentication: WebID, OpenID;q=0.9

In our particular case qvalue=1 could also mean that the server should
ask for a certificate in "need-mode" otherwise in "want-mode". Some
client implementations don't handle the "want-mode" in the right way and
don't even ask for a client certificate. In "need-mode" the client must
provide a certificate otherwise the server closes the connection with an
error. The "need-mode" should work with all implementations.

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


bergi

Received on Sunday, 6 November 2011 00:24:01 UTC