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

Brian Campbell bcampbell at pingidentity.com
Tue Feb 24 15:03:05 UTC 2015


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


More information about the Openid-specs-ab mailing list