Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:

> 
> Hi Julian,
> 
> On 02/21/2012 06:50 PM, Julian Reschke wrote:
>> On 2012-02-21 19:37, Stephen Farrell wrote:
>>> ...
>>>> I believe this should be orthogonal to HTTP/2.0. Is there a specific
>>>> thing that makes it impossible to use the existing authentication
>>>> framework?
>>> 
>>> Who knows? We don't have a protocol on the table yet. I
>>> would imagine that some level of backwards compatibility
>>> would be a requirement of course, or at least an issue to
>>> be considered.
>>> 
>>> But the existing HTTP client authentication is also not
>>> necessarily very useful, and there have been a number of
>>> efforts to improve on that, none of which seem to have
>>> gotten sufficient traction to get widely deployed/used.
>>> Maybe HTTP/2.0 is a good time to try fix that.
>> 
>> Well, we have an existing authentication framework. It would be
>> interesting to find out what's missing from it.
> 
> Fair point.
> 
> I would wonder whether that framework could be used
> as-is if HTTP/2.0 does do away "with the of HTTP/1.x
> message framing and syntax" but I guess some equivalent
> functionality could be defined in that case.

That shouldn't affect the framework at all. At most, you'd have to define how to re-serialise the current syntax if you don't have a way to "tunnel" it (since HTTP/1.1 passthrough is required).


> So as in my initial mail the 1st question here is, what
> does "modern" mean in this draft charter? E.g. does it
> mean "same as the current framework with different
> bits" or something else? If so, what?

As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.


> And then should it include adding some new options
> or MTI auth schemes as part of HTTP/2.0 or even looking
> at that? (I think it ought to include trying for that
> personally, even if there is a higher-than-usual risk
> of failure.)


Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project. 

Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.

Regards,


--
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 21 February 2012 22:40:32 UTC