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

Nat Sakimura sakimura at gmail.com
Wed Feb 25 00:43:19 UTC 2015


s/with values "no-store"/with a value "no-store"/

2015-02-25 9:41 GMT+09:00 Nat Sakimura <sakimura at gmail.com>:

> 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/20150225/73c61dd5/attachment-0001.html>


More information about the Openid-specs-ab mailing list