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/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf