[Openid-specs-ab] Form Post Response Mode example has 'Pragma: no-cache'

Nat Sakimura sakimura at gmail.com
Mon Mar 2 23:20:46 UTC 2015


+1

2015-03-03 7:30 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:

> Ok
>
> Sent from my iPhone
>
> On Mar 2, 2015, at 11:13 PM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
> +1 and echo what Justin said
>
> On Mon, Mar 2, 2015 at 2:56 PM, Justin Richer <jricher at mit.edu> wrote:
>
>> +1, this is a good balance between correctness and pragmatism.
>>
>>  — Justin
>>
>>
>> On Mar 2, 2015, at 4:54 PM, Mike Jones <Michael.Jones at microsoft.com>
>> wrote:
>>
>>  I think this is where we are:
>>
>>
>>
>> Add this normative text:
>>
>>
>>
>> "Because the Authorization Response is intended to be used only once, the
>> Authorization Server MUST instruct the User Agent (and any intermediaries)
>> not to store or reuse the content of the response."
>>
>>
>>
>> Use these directives in the example:
>>
>>
>>
>> Cache-Control: no-cache, no-store
>>
>> Pragma: no-cache
>>
>>
>>
>> Let’s close on the text to use during the call in just over an hour.
>> Talk to you soon…
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Brian Campbell [mailto:bcampbell at pingidentity.com
>> <bcampbell at pingidentity.com>]
>> *Sent:* Monday, March 02, 2015 1:46 PM
>> *To:* Mike Jones
>> *Cc:* John Bradley; Breno de Medeiros; <openid-specs-ab at lists.openid.net>
>> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example has
>> 'Pragma: no-cache'
>>
>>
>>
>> Though I still prefer that any normative text be somewhat general and
>> avoid mandating specif headers or values.  There was one such (rough)
>> proposal for text earlier in this thread.
>>
>>
>>
>> On Mon, Mar 2, 2015 at 2:29 PM, Brian Campbell <
>> bcampbell at pingidentity.com> wrote:
>>
>> Yeah, I guess I was hoping that some of the messiness of the internet was
>> old enough that it didn't have to be in new specs. But that was likely
>> silly.
>>
>> If we go with Mike's proposal, the example would have a "no-cache"
>> directive added to the "Cache-Control" response header. And the "Pragma:
>> no-cache" stays. *sigh*
>>
>>
>>
>>
>>
>> On Sat, Feb 28, 2015 at 7:00 PM, Mike Jones <Michael.Jones at microsoft.com>
>> wrote:
>>
>> In the example, I propose that we go with the directives that Google uses
>> in practice.  At least we have the weight of their data and usage behind
>> this choice.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net]
>> *On Behalf Of *John Bradley
>> *Sent:* Friday, February 27, 2015 2:48 PM
>> *To:* Breno de Medeiros
>> *Cc:* <openid-specs-ab at lists.openid.net>
>>
>>
>> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example has
>> 'Pragma: no-cache'
>>
>>
>>
>> Yes that was what I was trying to say on the call.   From my recollection
>> of working with caches you still need to send the HTTP 1.0 Pragma: no-cache
>> as some will ignore the HTTP 1.1.
>>
>>
>>
>> There are cable and satellite, and Christian/Children content filtering
>> proxies who I recall can be the worst.
>>
>>
>>
>> You are correct that it is not the right way to do it in HTTP 1.1,
>> however in HTTP 1.0 the behaviour was unspecified for Pragma: no-cache in
>> the response header.
>>
>> Most caches ignore it but some will honour it and ignore the others.
>>
>>
>>
>> I don’t know that there is a completely correct answer for a messy
>> internet.
>>
>>
>>
>> John B.
>>
>>
>>
>> On Feb 27, 2015, at 10:28 PM, Breno de Medeiros <breno at google.com> wrote:
>>
>>
>>
>>
>>
>> On Fri, Feb 27, 2015 at 1:15 PM, Brian Campbell <
>> bcampbell at pingidentity.com> wrote:
>>
>> Thanks Breno,
>>
>> I see you've got "Pragma: no-cache" there, which according to both RFC
>> 2616 <http://tools.ietf.org/html/rfc2616#section-14.32> and RFC 7234
>> <https://tools.ietf.org/html/rfc7234#section-5.4> isn't defined for the
>> response and isn't reliable for anti-caching. Having read that is what led
>> me to bringing this thread up in the first place. But I generally assume
>> that Google knows what they're doing so I have to ask - do you know why
>> that particular one is being used?
>>
>>
>>
>> I am not an expert on caching, but my understanding is that nearly all
>> clients compliant with HTTP 1.1 will process the 'modern' caching directive
>> on the cache-control entry and ignore pragma that comes later. However,
>> there are transparent caching proxies (or there used to be until
>> uncomfortably recently, specially in some regions of the world) that are
>> not actually HTTP 1.1 compliant (but allow the declaration from the
>> downstream client to be asserted, which they need to in any case). These
>> very old and bizarre proxies don't process correctly the cache-control
>> directive, but obey the older (HTTP 1.0) pragma directive, which is better
>> than nothing.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 26, 2015 at 7:45 PM, Breno de Medeiros <breno at google.com
>> > wrote:
>>
>> FWIW, the cache headers returned for some Google sensitive pages are:
>>
>>
>>
>> Cache-control: no-cache, no-store
>>
>> Pragma: no-cache
>>
>>
>>
>> The answer to the questions are yes and yes (where the first 'yes' should
>> mean to say 'modify the headers to a commonly agreed value that has clearer
>> no-caching semantics').
>>
>>
>>
>>
>>
>> On Thu, Feb 26, 2015 at 3:51 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>
>> If you can change "sensitive" to something else, I would be fine.
>> "Sensitive" has some connotation in the field of privacy and I do not want
>> confusion there.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-02-26 23:28 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>>
>> I'm fine with not wanting to use the word 'sensitive' but the text you
>> proposed doesn't seem quite right.
>>
>> While the "no-store" definition does mention non-volatile storage, it
>> also talks about volatile storage and, as I read it, pretty much says don't
>> store any part of the response or associated request, ever. From the text,
>> quoted again below, I don't see how "no-store" is possibly insufficient.
>> 5.2.2.3 <https://tools.ietf.org/html/rfc7234#section-5.2.2.3>.  no-store
>>
>>
>>
>>    The "no-store" response directive indicates that a cache MUST NOT
>>
>>    store any part of either the immediate request or response.  This
>>
>>    directive applies to both private and shared caches.  "MUST NOT
>>
>>    store" in this context means that the cache MUST NOT intentionally
>>
>>    store the information in non-volatile storage, and MUST make a
>>
>>    best-effort attempt to remove the information from volatile storage
>>
>>    as promptly as possible after forwarding it.
>>
>>
>>
>> Based on the text in the spec, I'm having a hard time understanding the
>> push back on using "no-store".
>>
>> From a practical perspective, however, I am not well versed in what
>> browsers and intermediate caches actual do and don't honor well. Generally,
>> when I want to prevent something from being cached, I throw a bunch of
>> anti-caching directives at the response and it just works out. To your
>> point earlier, that kind of thing isn't exactly appropriate for normative
>> text. Note also that there's not a implementation considerations section in
>> this doc and we're trying to make only very small changes at this point.
>>
>>
>>
>> As a compromise, of sorts, what about some text like this:
>>
>>
>>
>> "Because the Authorization Response is intended to be used only once, the
>> Authorization Server MUST instruct the User Agent (and any intermediaries)
>> not to store or reuse the content of the response."
>>
>>
>>
>> And then, in the non-normative example, just throw in the whole kitchen
>> sink of cache prevention headers like:
>>
>>
>>
>> Cache-Control: no-cache, no-store, max-age=0, must-revalidate, private
>> Expires: Thu, 01 Jan 1970 00:00:00 GMT
>>
>> ?
>>
>>
>>
>>
>>
>> On Tue, Feb 24, 2015 at 5:41 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>
>> Thanks Brian.
>>
>>
>>
>> A friendly amendment to your proposed change:
>>
>>
>>
>> Rationale
>>
>> -----------------
>>
>> 'sensitive' is either undefined or has other connotation especially in
>> the privacy realm, thus it probably is better to avoid the word in this
>> particular case.
>>
>>
>>
>> Also, "no-store" in our case is insufficient as cache control because it
>> is just concerned with a non-volatile storage.
>>
>>
>>
>> Proposal
>>
>> --------------
>>
>> Change:
>>
>> Because the Authorization Response contains sensitive information, the
>> Authorization Server MUST include the HTTP "Cache-Control" response header
>> field [RFC2616] with a value of "no-store" in the response.
>>
>>
>>
>> To:
>>
>> Because the Authorization Response contains the information that cannot
>> be re-used, the Authorization Server MUST include the HTTP "Cache-Control"
>> response header field [RFC7234] with values "no-cache" in the response.
>>
>>
>>
>>
>>
>> I have a slight concern about "no-cache" implementation state as RFC7234
>> says that it is not obeyed in some caches.
>>
>> "no-cache" is semantically equivalent to , "max-age=0, must-revalidate".
>> Perhaps it may be better to add that in practice, but it seems it is
>> inappropriate to have it in a normative text. Perhaps a note in an
>> implementation consideration may be good.
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>> 2015-02-25 0:15 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>>
>> And it just (re)occurred to me that RFC 2616 has been obsoleted. So the
>> reference in the text that I proposed in the last message should probably
>> be to RFC 7234 rather than RFC 2616.  Also the current reference in the
>> Form Post Response Mode to RFC 2616 for the "User Agent" term should
>> probably be updated to RFC 7230.
>>
>>
>>
>> On Tue, Feb 24, 2015 at 8:03 AM, Brian Campbell <
>> bcampbell at pingidentity.com> wrote:
>>
>> I think it'd be okay to have the "no-cache" directive the example as
>> well, if folks are keen on that. But it doesn't replace "no-store". The
>> example could have both like, "Cache-Control: no-cache, no-store". I don't
>> think it's necessary as "no-store" is the stricter but I think it's okay to
>> have it there too.
>>
>> On the call yesterday
>> <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150223/005280.html> I
>> asked if folks thought there should also be normative text in the Form Post
>> Response Mode doc about not caching the authorization response containing
>> the auto-submitting HTML form. There's some text in §5.1 of RFC 6749 /
>> OAuth 2.0  <http://tools.ietf.org/html/rfc6749#section-5.1>that could be
>> interpreted as obviating the need for it, which says that the
>> 'authorization server MUST include the HTTP "Cache-Control" response header
>> field [RFC2616] with a value of "no-store" in any response containing
>> tokens, credentials, or other sensitive information'.  However, that's in a
>> section about the token endpoint and so could also be interpreted as not
>> applying to the authorization response from the authorization endpoint at
>> all. Thus, I'm (sorta) proposing to add the following sentence to the end
>> of §2 of OAuth 2.0 Form Post Response Mode
>> <http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html#FormPostResponseMode>,
>> 'Because the Authorization Response contains sensitive information, the
>> Authorization Server MUST include the HTTP "Cache-Control" response header
>> field [RFC2616] with a value of "no-store" in the response.'
>>
>>
>>
>> On Mon, Feb 23, 2015 at 4:55 PM, Brian Campbell <
>> bcampbell at pingidentity.com> wrote:
>>
>> But that text is about directives on the cache-control _request_ header.
>>
>> The directives in question here are on the _response_.
>>
>> https://tools.ietf.org/html/rfc7234#section-5.2.2 is about the response
>> directives. With https://tools.ietf.org/html/rfc7234#section-5.2.2.3 saying
>> this about "no-store",
>>
>>    The "no-store" response directive indicates that a cache MUST NOT
>>
>>    store any part of either the immediate request or response.  This
>>
>>    directive applies to both private and shared caches.  "MUST NOT
>>
>>    store" in this context means that the cache MUST NOT intentionally
>>
>>    store the information in non-volatile storage, and MUST make a
>>
>>    best-effort attempt to remove the information from volatile storage
>>
>>    as promptly as possible after forwarding it.
>>
>> While "no-cache" at https://tools.ietf.org/html/rfc7234#section-5.2.2.2 isn't
>> as strong:
>>
>>    The "no-cache" response directive indicates that the response MUST
>>
>>    NOT be used to satisfy a subsequent request without successful
>>
>>    validation on the origin server.  This allows an origin server to
>>
>>    prevent a cache from using it to satisfy a request without contacting
>>
>>    it, even by caches that have been configured to send stale responses.
>>
>>
>>
>>
>>
>> On Mon, Feb 23, 2015 at 4:39 PM, Mike Jones <Michael.Jones at microsoft.com
>> > wrote:
>>
>> Brian, “Cache-control: no-store” does not seem to imply “Cache-control:
>> no-cache”.  I say that because of this sentence in 5.2.1.5 of
>> https://tools.ietf.org/html/rfc7234#section-5.2.1:
>>
>>
>>
>>    Note that if a request containing this directive is satisfied from a
>>
>>    cache, the no-store request directive does not apply to the already
>>
>>    stored response.
>>
>>
>>
>> Therefore, to be safe, I believe that we have to replace the “Pragma:
>> no-cache” in our example with “Cache-control: no-cache”.
>>
>>
>>
>> Do people agree with that conclusion?
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
>> *Sent:* Thursday, February 19, 2015 7:19 PM
>> *To:* Mike Jones
>> *Cc:* Brian Campbell; <openid-specs-ab at lists.openid.net>
>> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example has
>> 'Pragma: no-cache'
>>
>>
>>
>> Yes and yes.
>>
>>
>>
>> On Feb 19, 2015, at 5:08 PM, Mike Jones <Michael.Jones at microsoft.com>
>> wrote:
>>
>>
>>
>> First question to the working group:  Do we agree that "Pragma: no-cache" should
>> be changed to "Cache-Control: no-cache" in the Form Post Response Mode
>> spec before approval?
>>
>>
>>
>> Second question to the working group:  If we agree to make this change
>> (to text that only occurs in a non-normative example), are people
>> comfortable doing this without restarting the 60 day review period (but
>> still notifying people of the change)?
>>
>>
>>
>> My personal answers would be “yes” and “yes” but we shouldn’t do this at
>> this point unless there’s working group consensus to do so.
>>
>>
>>
>> Brian, could you also send a note to the OAuth working group pointing
>> this problem with RFC 6749 and RFC 6750 and asking whether errata should be
>> filed?  This would help get more expert eyes on the issue.
>>
>>
>>
>> Thanks for bringing this to our attention, Brian!
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net
>> <openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of *Brian Campbell
>> *Sent:* Thursday, February 19, 2015 2:17 PM
>> *To:* <openid-specs-ab at lists.openid.net>
>> *Subject:* [Openid-specs-ab] Form Post Response Mode example has
>> 'Pragma: no-cache'
>>
>>
>>
>> The example response in
>> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0-03.html#FormPostResponseExample has
>> a "Pragma: no-cache" response header.
>>
>> However both RFC 2616 <http://tools.ietf.org/html/rfc2616#section-14.32> and
>> the shiny new RFC 7234 <https://tools.ietf.org/html/rfc7234#section-5.4> make
>> special note along the lines of the following to say that it doesn't work
>> as response header:
>>
>>       'Note: Because the meaning of "Pragma: no-cache" in responses is
>>
>>       not specified, it does not provide a reliable replacement for
>>
>>       "Cache-Control: no-cache" in them.'
>>
>>
>> It doesn't really hurt anything having it in the Form Post Response Mode
>> document but I'm thinking it'd be better to not further perpetuate the
>> "Pragma: no-cache" response header myth in this specification* and that
>> that line should probably be removed from the example.
>>
>> Or am I wrong on this? And if so, what am I missing?
>>
>>
>>
>> * And, yeah, it's in Connect Core and OAuth 2.0 as well but I figured
>> starting with a draft that wasn't yet final was good.
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>>
>> --
>>
>> Nat Sakimura (=nat)
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Nat Sakimura (=nat)
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>>
>> --
>>
>> --Breno
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> --Breno
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>>   _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150303/269a128d/attachment-0001.html>


More information about the Openid-specs-ab mailing list