Subject: [OAUTH-WG] No caching?

From: Hubert Le Van Gong <[email-masked]>
Date: Mon, 9 Nov 2009 10:04:17 +0100

Section 6.6 explains there might be issues with caching but
I wonder if we shouldn't go a bit further in securing the protocol
messages. Shouldn't we prevent caching for at least some of
the protocol messages?

I find the rules in the SAML 2.0 spec fairly clear in this matter
(see below).

- Include Cache-Control header, set to "no-cache, no-store"
- Include Pragma header, set to "no-cache"
- Not include validator like Last-Modified or Etag header

Even if we decide not to mandate those, would it be useful
to list those as a recommendations?

Hubert

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Mon, 9 Nov 2009 11:03:11 -0500

I think there are very real use cases where I would expect (and desire)
the response to an OAuth-signed request to be at least "private"
cacheable, so I'm not sure I would go so far as to *recommend* (i.e.
SHOULD) the full "no-cache" approach. Also, RFC2616 specifies:

"In other words, the preferred behavior for an HTTP/1.1 origin server is
to send both a strong entity tag and a Last-Modified value."

It also goes so far as to say you SHOULD generate an ETag unless this is
technically infeasible, and I don't think the OAuth case qualifies here.
I'm not sure I can back not including validators in the response.

In my case, I would do:

Cache-Control: private, no-store, max-age=600
Last-Modified: <same as Date header>
Expires: <same as Date header, or "0">
Etag: <as generated>

Which allows for caching by HTTP/1.1 private caches but prevents caching
by HTTP/1.0 caches.

All that being said, however, the HTTP RFC is the source of truth as far
as caching goes, and I would rather have the OAuth spec refer directly
to it, much as it already does, with the "be careful what you're doing
here" caveat. It might be useful, however, to call out particular
portions of RFC2616 to implementors, such as Section 13 and the
definitions of the individual headers in Section 14 for 'Etag',
'Last-Modified', 'Expires', 'Cache-Control', and 'Pragma'.

It is also worth noting that caches may be explicitly configured to
override caching directives from clients and/or servers, and hence the
security of the protocol must not depend on having fully-compliant
proxies and caches.

Jon
........
Jon Moore
Comcast Interactive Media

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hubert Le Van Gong
Sent: Monday, November 09, 2009 4:04 AM
To: [email-masked]
Subject: [OAUTH-WG] No caching?

Hubert
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth