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

Wed Feb 25 00:41:58 UTC 2015

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