W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: FYI: proposal for client authentication in TLS

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Tue, 11 Mar 2014 11:17:12 +0200
Message-ID: <CAGvU-a7T4Z8VB-vZc3YbOTq7O=PC-_ihiN8aiVmqXL6QD9Uz+w@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Mar 11, 2014 at 9:57 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

>
> I'd much rather this new authentication scheme was HTTP version
>> independent.
>>
>
> Well, the scheme itself *is* version independent. It's "just" harder to
> deploy with 1.1.
>
> Is there an *alternative*, given the HTTP/2 constraints?
>

I think the constraint belongs to HTTP/1, that doesn't have a way to
advertise new capability. It would be good if the client had a way to
signal to the server (either through TLS or through HTTP) that it
understands the ClientCertificate authentication method. In that case, the
server could choose whether to initiate renegotiation or to send this
WWW-Authenticate header based on that support.

Incidentally, this could also be an issue for any new authentication scheme
such as those discussed in httpauth, but for those there are no
alternatives - either you support them or you don't. Here there is an old
way of doing things.

An obvious alternative is to define some new header
"SupportedAuthenticationMethods" that the client would send. But adding
this kind of thing to every request is a waste.
I suppose servers could do the cringe-worthy thing of identifying
supporting browsers based on their UA strings.

But no, I don't see a good alternative.

Yoav
Received on Tuesday, 11 March 2014 09:17:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC