OverviewΒΆ
CNP 0.4 does not have an equivalent of HTTP cookies, nor is there a real need for them so far, since CNM 0.4 does not support forms and thus data submission and authentication. However, once CNM gets forms, having a way to keep state in CNP would be very useful, since that would facilitate persistent log-ins and user settings on sites.
HTTP cookies have numerous problems. CNP would need a way to avoid most of them.
Session leakage could be remedied by limiting it to the specific request hostname (potential port number included) that the session initiation was a response to. While this would have an impact on cross-domain authentication, the latter can still be performed using different means (e.g. queries followed by redirects). Alternatively, sessions could whitelist specific subdomains of the current host that the session may be used on.
Unlike common HTTP cookie implementations, CNP sessions should be obvious to the user. An interactive user-agent could prompt the user to accept the session and provide a clear indication of whether a session is active on the current host (or any embedded content in the page), providing an accessible way to close it.
Limiting sessions to one per host might be beneficial to avoid putting excessive state data in the request headers.
Technologies such as HMAC could be used to both prevent cookie sniffing once session is up and verify the integrity of all headers and/or bodies of requests within the session. Additionally, this would mean that the session value is just the server-issued secret key that would not be sent with every request, forcing the server to store state locally instead of having the client send it on every request.