[IdPv3] Cookies

[Chad La Joie]

So, an issue that comes up now and again with IdPv2 is its use of
cookies.  As the plan is to use cookies more in IdPv3, as a means of
carrying longer-term state, I wanted to post my current thinking.  I
recommend anyone who really cares about this reads RFC6256[1] first.
Also, most of these items are interrelated in various ways so read
through the whole mail (probably a couple times) before commenting.

- Cookie names will be determined by a naming strategy and will
contain a 2-digit numeric suffix used for ordering the cookies when
they are sent back to the server

- If the value of a cookie would exceed 4k, the value will be chunked
and distributed across multiple cookies

- The cookie will use the Expires attribute (as opposed to Max-Age) to
convey the expiration time (if any)

- The cookie will use the server's hostname, or a configured hostname,
as the value for the Domain attribute

- The cookie will use the Servlet's context path, or a configured
path, as the value of the Path attribute

- The cookie will set the Secure attribute if the scheme of the
request is HTTPS; a configuration option will be available to disable
setting this attribute

- The cookie will set the HttpOnly attribute; a configuration option
will be available to disable setting this option

- In addition to the value given for the cookie, the following
information may also (indicated by configuration options) be encoded
into the cookie value: user agent IP, cookie domain, server port,
Servlet context path, whether the cookie was sent to the user agent
over a secure transport, a signature.

- If the cookie is signed the signature will be over the user supplied
value, the previously mentioned additional data, and an indicator that
the content was signed

- The whole cookie value string may be encrypted

- Upon receipt of the cookie the service may, as determined by
configuration, check:
  - that the user agent IP address matches the IP encoded in the cookie value
  - that the server host that received the cookie matches, or is a
subdomain, the domain encoded in the cookie value
  - that the server port that received the cookie is the same as the
port encoded in the cookie value
  - that the request path is the same as, or a subpath, of the path
encoded in the cookie value
  - that if the cookie was returned over HTTPS if it was provided to
the user agent over HTTPS
  - that the cookie was signed
  - that the cookie signature is valid

Many of the previously mentioned checks are, in theory, performed by
the user-agent.  However, as noted in RFC6265, there are ways to
circumvent these features.  When the server performs the checks, it
can at least protect itself from some forms of attack.  If there are
additional checks that could be performed, feel free to suggest them.

[1] http://tools.ietf.org/html/rfc6265
-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered