[jasonwatkinspdx]

They are different because a server suggested resumable session nonce requires no form based authentication. User entered entropy never hits the wire. I do not know how to emphasize this point more strongly. Please read the research on trends in brute force and timing attacks vs human capacity for entropy memorization.

Evidence is clear: The majority of sites do not handle cookies securely. They do not handle user submitted entropy securely. Virtually no one supports 2 factor authorization (props to google on this point).

The scheme I am suggesting and the status quo are not equivalent as you suggest. I do agree that they are orthogonal, except at the point where we decide upon a standard.

I take it as a given that the status quo is unacceptable. If you disagree there's not much for us to discuss.

What I'd like to see is http/2 be a fresh design that is unwilling to sacrifice security. We can always assume http/1.1 or failback to it under negotiation. Because of that, there is no reason to burden a new standard with backwards comparability. Among the SPDY community you see this same perspective, often suggested as a tick/tock strategy where when version n+2 goes online version n+1 becomes backport only support and version n is abandoned.

[comex]

Server suggested resumable session nonce is just a cookie. If you want the user to be able to put in a password without sending it in plaintext to the server (i.e. make HTTP authentication actually work properly) that would be really really great but, I think, also a different proposal.

Well... I don't think it's worth drawing a line in the sand here, because the speed and, should TLS-always-on make it in, security benefits of the existing protocol are significant enough that everyone should be able to use them without rewriting their authentication system. But I'd certainly be for a comprehensive proposal for a new authentication system; it would probably be significantly cleaner than BrowserID.