Inconsistencies found in OpenID Provider's HTTP Headers. Which one is the most secure that I should imitate in my STS, and Relying Party?

Question

I'm comparing the HTTP headers of the various providers (LiveID, Google, Yahoo, etc) and notice a broad inconsistency in implementation on the sign in page, sign out page, and subsequent pages.

What headers should I set/ignore, and what is the correct value to use in the following scenarios:

• SignIn
• General usage (HTTPS only site, or regular HTTP)
• SignOut

Here are a list of headers that I've noticed and the differences among them. I'm sure that each company had smart people implement or omit certain headers for a reason; I just can't tell which provider has the best implementation.

My bet is that each provider has something the others can learn from.

Expires:

• LiveID sets the Expires header to exactly one minute prior to the current time
• Google and MyOpenID has the Expires header equal to the current time
• Yahoo Expires at Thu, 05 Jan 1995 22:00:00 GMT
• Verisign PIP Expires at Thu, 01 Jan 1970 00:00:00 GMT
• Facebook Expires Sat, 01 Jan 2000 00:00:00 GMT
• ADFSv2 -1
• Not present in Azure ACS

Cache Control:

• Yahoo & Azure ACS: private
• Facebook: private, no-cache, no-store, must-revalidate
• MyOpenID: max-age=86400
• PIP: no-cache,no-store,max-age=0
• ADFSv2: no-cache

Pragma

• Yahoo, LiveID, Facebook: no-cache
• Google, MyOpenID, Azure ACS value does not exist.

X-Content-Type-Options: IE8 Details, IE9 Details

• Azure ACS, Google, : nosniff

X-XSS-Protection Details More details

• Facebook, LiveID, ADFSv2 : 0
• Google: 1; mode=block
• Not present in Azure ACS and other providers

X-Frame-Options More Details

• Yahoo: X-Frame-Options: DENY
• Google: SAMEORIGIN

Access-Control-Allow-Origin (How to use with multiple domains)

• Google (conditions apply)

Strict-Transport-Security See also how to disable for debugging

• Google (conditions apply)
• PayPal / Lastpass (500 seconds = bit over 8 minutes)
• market.android.com (2592000 seconds = 30 days)

X-Pad // A fix for very very old versions of Netscape

• Verisign PIP

Lastly it's interesting that Facebook has two headers regarding the HTTP Connection X-Cnection: close and Connection: Keep-Alive. I'm not sure if they are relevant but I'm including them here for completeness.

Answer 1

Use HTTPS, cachin/expires won't matter. X-XSS-Protection as Google does. Strict-Transport-Security (and the subdomain directive) nosniff, blame IE. X-Pad... if someone using using Netscape... there are bigger problems.