Directive "Pragma" no-cache

[Andrii Deinega]

Both specifications https://openid.net/specs/openid-connect-frontchannel-1_0-05.html and https://openid.net/specs/openid-connect-backchannel-1_0-07.html may omit the “Pragma“ directives.

This is a backward compatibility directive for old HTTP 1.0, and this directive is for an HTTP request, not a response. There was a discussion on that in OAuth2 WG here quite long ago.

In addition to that, the Cache-Control may include only “no-store“, as it already includes “no-cache” per https://datatracker.ietf.org/doc/html/rfc7234#section-5.2.1.5.

[Michael Jones]

What is the specific specification change you are requesting? I can’t tell from the issue description.

[Andrii Deinega]

I suggest removing all uses of “Pragma: no-cache“. The same applies to the OpenID Connect Core specification.

Plus, change

Cache-Control: no-cache, no-store

to

Cache-Control: no-store

BTW, the core specification uses the latter.

[Michael Jones]

I’m curious @Brian Campbell ,@Filip Skokan , and @Joseph Heenan what you think of this suggestion.

[Filip Skokan]

I agree with removing pragma. I will defer the “content of cache-control“ to others more versed in the semantics.

[Brian Campbell]

Definitely remove pragma.

And, as far as I understand it, no-store is the strongest anti-cache directive that is sufficient alone and the one that actually means ‘don’t cache this' so Cache-Control: no-store is okay.

[Joseph Heenan]

I agree with changing Cache-Control to just no-store, and doing so brings logout into line with Connect & RFC6749.

I don’t know what to do about Pragma. Both OIDCC and RFC6749 explicitly have a MUST for pragma in token endpoint responses, though it does seem to have been dropped in OAuth 2.1. Removing it from logout likely makes sense. Is removing Pragma from OIDCC in an errata possible?

‌

[Joseph Heenan]

(The OIDCC part of the discussion is probably best continued in Filip’s new issue, https://bitbucket.org/openid/connect/issues/1488/certification-query-checking-do-not-cache )

[Andrii Deinega]

@Joseph Heenan , it was dropped in OAuth 2.1, this change is a part of the latest draft https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-05 available as of today.

[Andrii Deinega]

What’s also quite interesting about the cache-control HTTP header is that it holds cache directives not only for responses but for requests as well. The “no-store“ directive

The "no-store" request directive indicates that a cache MUST NOT
store any part of either this request or any response to it. 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.

per https://datatracker.ietf.org/doc/html/rfc7234#section-5.2.1.5.

It means that it might make sense to use this directive for certain requests that contain sensitive data hoping that, for example, the browser will make an attempt to remove it from the memory. Of course, there is no guarantee for that and RFC 7234 says

This directive is NOT a reliable or sufficient mechanism for ensuring privacy.

Although I believe, the same applies to any other directives.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/167/use-cache-control-no-store

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/167/use-cache-control-no-store