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

Re: non authenticated alternate services (was Re: AD review of draft-ietf-httpbis-alt-svc-10)

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 18 Jan 2016 15:32:41 -0500
Message-ID: <CAOdDvNrbszUAMhK_T-5skM2JPvvcC7meaP0TmHQNJefrX2mxzA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Patrick McManus <pmcmanus@mozilla.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mike Bishop <Michael.Bishop@microsoft.com>, Barry Leiba <barryleiba@computer.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, "draft-ietf-httpbis-alt-svc@ietf.org" <draft-ietf-httpbis-alt-svc@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Jan 17, 2016 at 7:23 PM, Mark Nottingham <mnot@mnot.net> wrote:

> > What is "strongly authenticate" ? It may be read that some kind
> certificate must be always
> > required.
> We're leaving that intentionally vague.

I think the problem is that it doesn't feel very vague - strongly
authenticate should principally mean via crypto auth.. so I think its a
notch stronger than we're looking for here. The other confusing bit is
that, using the proposed .w-k approach, you're not really authenticating
the alternate as much as you're authenticating that alternate is valid for
the whole origin (as you indicate below).

> If the phrase "strong authentication" is making this hard to understand,
> we might use something else (e.g., "have reasonable assurances that the
> alternative service is under control of the origin").

that's better. maybe tweak with the "valid for the whole origin" concept?
That would certainly include both valid cert as well as the .wk approach..
Received on Monday, 18 January 2016 20:33:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC