-----
This specification does not define what makes an HTTP-only cookie, and at the time of publication the editor is not aware of any reference for HTTP-only cookies. They are a feature supported by some Web browsers wherein an "httponly" parameter added to the cookie string causes the cookie to be hidden from script.
------

The latest XHR draft does cover sending and receiving the cookie headers (not allowing them to be intercepted or overwritten).  Neither really delve into specifics, so we're hoping to add clarification to UA implementers.

But beyond that, there's two more issues that we're working on:

(1) Figuring out how to add integrity protection on top of confidentiality protection.  That is, how to prevent an attacker from overwriting HTTPOnly cookies with his/her own cookie.

(2) Figuring out how to add privacy protection on top of confidentiality protection.  That is, how to prevent an attacker from learning if a HTTPOnly cookie has been set.

We came to the conclusion that #2 wasn't possible, at least not without creating a "namespace"-type system where HTTPOnly cookies can co-exist along side a JavaScript-created cookie of the same name.  And #1 is being debated currently, we may have to drop it too as it will also require some fancy footwork I think.

You can see our current work here, although it doesn't reflect some of the newer discussions we've had:

        https://docs.google.com/View?docid=dxxqgkd_0cvcqhsdw

One option I'm considering is doing as you suggest, writing an entire cookie spec as it exists now, then add the features to cookies necessary to provide integrity and privacy.  I spoke with Ian Hickson, he said IETF is the proper place for this work, not WHATWG.

- Bil