- From: <henry.story@bblfish.net>
- Date: Wed, 26 Mar 2014 09:34:53 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
On 21 Mar 2014, at 02:12, Mark Nottingham <mnot@mnot.net> wrote: > > On 20 Mar 2014, at 1:42 am, henry.story@bblfish.net wrote: > >> So presumably here one could extend the current client "Authorization" header to >> something like >> >> Authorization: Certificate >> >> So I see that new schemes can be registered at >> >> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-26#section-5.1.2 >> https://www.ietf.org/rfc/rfc2617.txt >> >> This does require server side TLS renegotiation to work, but that's where we are at >> present. > > I think this makes the most sense, in that then you could send > > Vary: Authorization > > to indicate that the response varies based upon that header. > Might be good to put a hash of the cert into the header... In current popular browsers it is not possible for JS to access the certificates in the keystore, or to calculate their hashes. [1] This would be possible for web crawlers though ( since those can be programmed to do whatever we want ). In both cases giving the hash of a certificate in advance could leak identifying information, and would require the client to have made up its mind in advance as to what certificate it wanted to use. But I suppose if the request follows a response containing a "WWW-Authenticate: Certificate" header or if the client knows that it wants to be identified, then that would make sense anyway. What was the situation in which you could see an advantage of putting a hash of the cert in the header ? ( which header?) Thanks, Henry [1] But I have not followed carefully the Web Crypto APIs evolution. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > Social Web Architect http://bblfish.net/
Received on Wednesday, 26 March 2014 08:35:30 UTC