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

Nat Sakimura sakimura at gmail.com
Thu Feb 26 23:51:41 UTC 2015


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


More information about the Openid-specs-ab mailing list