- From: <henry.story@bblfish.net>
- Date: Mon, 21 Sep 2015 16:43:49 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
> On 21 Sep 2015, at 15:28, Kyle Rose <krose@krose.org> wrote: > >>> The difference is that now the sane design is mandatory, else you get unpredictable results. A sane design works with renegotiation, #209 and HTTP-layer authentication >> >> Not even then. Client may reuse connections on matching certs. There are installations out there that have a cert for +3 domain names, lets say A, B and C. A has anonymous access, B and C both require different client certs. Depending on which tab the browser load first, the one or the other cert gets loaded in, leading the other site to fail since the cert is not accepted. > > Yeah, this is a huge issue that doesn't appear in HTTP/1.1. It sounds > to me like the real problem is trying to shoehorn application-layer > client authentication into the transport layer. How is this different from say if one authenticated to each resource using public keys at the HTTP layer [1]. We could imagine here A, B and C, being resources on the same server even with A only accessible by somone who can prove he is over 18, the other by someone how is a member of this working group, ( provable using either a WebID or an OpenID ), etc.... There are two signals the server can set up to help the user agent select a certificate: A 401 not Authorized, and perhaps a link to an access control resource that would describe who can have access [2]. The client needs some logic to help select a certificates or credential to respond to the request while putting the user in control, and without being too much of a pain. As I understand Martin Thomson suggested an HTTP header WWW-Authenticate: Certificate sent at the HTTP layer, that could then start the certificate connection at the TLS layer. The client could also try to narrow down from the ACL list to see if it is even worth bothering the user to ask him for a Certificate, and perhaps warn him that some links cannot be followed, because of the lack of access. It is true that authentication at the TLS layer is much rougher, as I think the client can only authenticate with 1 certificate not more, per connection. But part of the problem you mention has more to do with the logic of the user agents credential selection and the problems of protected resources across origins ( which everybody is familiar when looking at YouTube links that are viewable in one country but not in another ). Henry [1] As suggested by one of the following • Andrei Sambra's first sketch authentication protocol https://github.com/solid/solid-spec#webid-rsa • Manu Sporny's more fully fleshed out HTTP Message signature https://tools.ietf.org/html/draft-cavage-http-signatures-04 [2] Following work described here for example http://www.w3.org/wiki/WebAccessControl > > Kyle Social Web Architect http://bblfish.net/
Received on Monday, 21 September 2015 15:44:19 UTC