That works.
>________________________________
> From: Mike Jones <michael.jo...@microsoft.com>
>To: "oauth@ietf.org" <oauth@ietf.org>
>Sent: Thursday, May 17, 2012 3:12 PM
>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:squ...@treenet.co.nz]
>Sent: Monday, April 23, 2012 10:13 PM
>To: Mike Jones
>Cc: oauth@ietf.org
>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: oauth-boun...@ietf.org On Behalf Of Amos Jeffries
>> Sent: Monday, April 23, 2012 7:10 PM
>> To: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
>>
>> On 24.04.2012 13:46, internet-dra...@ietf.org 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
