- From: Hervé Ruellan <herve.ruellan@crf.canon.fr>
- Date: Fri, 30 Jan 2015 13:34:23 +0100
- To: <ietf-http-wg@w3.org>
I think it's a good thing to have a common mechanism that could be reused by several authentication schemes (at least DIGEST and SCRAM for now). I find that the definition of the Authentication-Info header field is fuzzier in this draft than it was in DIGEST. In DIGEST this header field is intended to be used for "information regarding the successful authentication of a client response". I'd tweak the wording in the draft to put back this precision. I think it would alleviate Martin's concerns. Or did I miss something? Regards, Hervé. On 01/29/2015 08:41 AM, Julian Reschke wrote: > On 2015-01-29 01:21, Martin Thomson wrote: >> On 28 January 2015 at 14:45, Mark Nottingham <mnot@mnot.net> wrote: >>> Julian has proposed that >>> <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be >>> adopted by this WG, with the aim of getting to LC quickly so that it >>> can be referenced by other efforts. >> >> I'd like to see the fact that this is a *response* header field more >> prominent in the document. The word "return" is used, but in this >> context, that's fairly ambiguous. > > Will do. > > (Which reminds me that in the list of considerations for new header > fields in 7231, most apply to request header fields; we may want to > restructure that text in the future) > >> More fundamentally, I see a correlation issue if clients provide >> multiple *Authorization header fields. The response they receive will >> contain some unaggregated name-value pairs in this header field. >> >> "Its semantics are defined by the applicable authentication scheme." >> >> I don't know how that can be interpreted in the general sense since >> there isn't a way of identifying the corresponding scheme. >> >> And doesn't it need anti-collision machinery for the parameters? > > See Yutaka's answer. > > Best regards, Julian >
Received on Friday, 30 January 2015 12:34:53 UTC