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

Breno de Medeiros breno at google.com
Fri Feb 27 02:45:16 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150226/34f1a730/attachment-0001.html>


More information about the Openid-specs-ab mailing list