Private also seems inappropriate since no operation should be cached for oauth as even when the same requestor.
Phil On 2012-06-11, at 12:17, Torsten Lodderstedt <[email protected]> wrote: > Hi all, > > I noticed a difference in usage of cache control headers between bearer and > core spec. > > core -27 states: > > " 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, as well as the "Pragma" response header field [RFC2616] > with a value of "no-cache"." > > So a "Pragma" response header field is required instead of the > "Cache-Control" header "private". > > As far as I understand, both specs are nearly but not fully equivalent. Do we > need to align both? > > regards, > Torsten. > > Am 09.06.2012 00:20, schrieb Mike Jones: >> >> Hi Amos, >> >> The OAuth Bearer specification now includes the Cache-Control language we’d >> discussed. >> >> See the fifth paragraph of >> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. >> >> Thanks again, >> -- Mike >> >> >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Mike Jones >> Sent: Thursday, May 17, 2012 3:12 PM >> To: [email protected] >> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter >> method >> >> Dear working group members: >> >> I'm going through the remaining open issues that have been raised about the >> Bearer spec so as to be ready to publish an updated draft once the >> outstanding consensus call issues are resolved. >> >> Amos Jeffries had cited this requirement in the HTTPbis spec ( >> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): >> >> o The credentials carried in an Authorization header field are >> specific to the User Agent, and therefore have the same effect on >> HTTP caches as the "private" Cache-Control response directive, >> within the scope of the request they appear in. >> >> Therefore, new authentication schemes which choose not to carry >> credentials in the Authorization header (e.g., using a newly >> defined header) will need to explicitly disallow caching, by >> mandating the use of either Cache-Control request directives >> (e.g., "no-store") or response directives (e.g., "private"). >> >> I propose to add the following text in order to satisfy this requirement. I >> have changed Amos' MUSTs to SHOULDs because, in practice, applications that >> have no option but to use the URI Query Parameter method are likely to also >> not have control over the request's Cache-Control directives (just as they >> do not have the ability to use an "Authorization: Bearer" header value): >> >> Clients using the URI Query Parameter method SHOULD also send a >> Cache-Control header containing the "no-store" option. Server success >> (2XX status) responses to these requests SHOULD contain a Cache-Control >> header with the "private" option. >> >> Comments? >> >> -- Mike >> >> -----Original Message----- >> From: Amos Jeffries [mailto:[email protected]] >> Sent: Monday, April 23, 2012 10:13 PM >> To: Mike Jones >> Cc: [email protected] >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt >> >> On 24/04/2012 4:33 p.m., Mike Jones wrote: >> > What specific language would you suggest be added to what section(s)? >> > >> > -- >> > Mike >> >> >> Perhapse the last paragraph appended: >> " >> >> Because of the security weaknesses associated with the URI method >> (see Section 5), including the high likelihood that the URL >> containing the access token will be logged, it SHOULD NOT be used >> unless it is impossible to transport the access token in the >> "Authorization" request header field or the HTTP request entity-body. >> Resource servers compliant with this specification MAY support this >> method. >> >> Clients requesting URL containing the access token MUST also send a >> Cache-Control header containing the "no-store" option. Server success >> (2xx status) responses to these requests MUST contain a Cache-Control >> header with the "private" option. >> >> " >> >> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely >> should be a MUST NOT to further discourage needless use. >> >> >> AYJ >> >> >> > >> > -----Original Message----- >> > From: [email protected] On Behalf Of Amos Jeffries >> > Sent: Monday, April 23, 2012 7:10 PM >> > To: [email protected] >> > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt >> > >> > On 24.04.2012 13:46, [email protected] wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. This draft is a work item of the Web Authorization >> >> Protocol Working Group of the IETF. >> >> >> >> Title : The OAuth 2.0 Authorization Protocol: Bearer >> >> Tokens >> >> Author(s) : Michael B. Jones >> >> Dick Hardt >> >> David Recordon >> >> Filename : draft-ietf-oauth-v2-bearer-19.txt >> >> Pages : 24 >> >> Date : 2012-04-23 >> >> >> >> This specification describes how to use bearer tokens in HTTP >> >> requests to access OAuth 2.0 protected resources. Any party in >> >> possession of a bearer token (a "bearer") can use it to get >> >> access to >> >> the associated resources (without demonstrating possession of a >> >> cryptographic key). To prevent misuse, bearer tokens need to be >> >> protected from disclosure in storage and in transport. >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt >> > >> > >> > The section 2.3 (URL Query Parameter) text is still lacking explicit and >> > specific security requirements. The overarching TLS requirement is good in >> > general, but insufficient in the presence of HTTP intermediaries on the >> > TLS connection path as is becoming a common practice. >> > >> > The upcoming HTTPbis specs document this issue as a requirement for new >> > auth schemes such as Bearer: >> > >> > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 >> > " >> > Therefore, new authentication schemes which choose not to carry >> > credentials in the Authorization header (e.g., using a newly >> > defined header) will need to explicitly disallow caching, by >> > mandating the use of either Cache-Control request directives >> > (e.g., "no-store") or response directives (e.g., "private"). >> > " >> > >> > >> > AYJ >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
