Developers of say a mobile app would not have to deploy it since the redirect 
endpoint would be local per the specific exception proposed. There should be NO 
requirement to make a client app implement TLS server side security. 

The concern here is that all "network" paths are secured to prevent 
impersonation or theft of the session. Remember that in many cases, once the 
code is granted, the subsequent token is often good for a LONG time and thus 
this becomes the weak point in this protocol.

Re: Justin's comments on SHOULD, I find SHOULD is just too broad, it does not 
define when it is acceptable not to have security.  I prefer clear 
specification text that says the network paths must be protected.

Re: Eran's comments about impact on the existing community.  I don't think you 
are grasping the broadness of acceptance of OAuth 2.0. The existing OAuth 1.0 
users are primarily social networks. I haven't heard them object. In fact, I've 
noticed almost all have started enabling HTTPS everywhere (at least as a user 
option). But OAuth2 has a much broader community now that I would argue is VERY 
concerned about risks of impersonation and real financial loss.

Phil
phil.h...@oracle.com




On 2011-03-30, at 8:19 AM, Dick Hardt wrote:

> Thanks for pointing out my misunderstanding. I was thinking client in the 
> sense of the side of TLS initiating a request.
> 
> I agree that requiring TLS on the callback is an unexpected change. 
> 
> I recall reviewing the security implications of an unsecured callback as 
> being nominal if the authorization grant is linked to the client credentials.
> 
> 
> On 2011-03-29, at 10:07 PM, Eran Hammer-Lahav wrote:
> 
>> I think you got this backwards. We’re talking about forcing developers using 
>> the Facebook (or any other service) API to deploy their own TLS endpoint for 
>> the incoming callback (via redirection). Every developer will need to get a 
>> cert and deploy an HTTPS endpoint.
>>  
>> That’s has never been discussed.
>>  
>> EHL
>>  
>> From: Dick Hardt [mailto:dick.ha...@gmail.com] 
>> Sent: Tuesday, March 29, 2011 9:02 PM
>> To: Eran Hammer-Lahav
>> Cc: WG
>> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
>>  
>>  
>> On 2011-03-29, at 4:40 PM, Eran Hammer-Lahav wrote:
>> 
>> 
>> To clarify, I am not opposed to mandating TLS on the callback, just that if 
>> we do, we can’t ship the protocol the way it is without coming up with some 
>> other alternative that does not require TLS deployment on the client side. 
>> OAuth 1.0 has no such requirement and adding it in 2.0 is completely 
>> unexpected by the community at large.
>>  
>> I only recall the concern with TLS to be on the server side, not the client 
>> side -- and I don't think that it is unexpected at all.
>> 
>> 
>>  
>> It would be helpful to hear from some companies with large 1.0 or 2.0 
>> deployment on this matter? Anyone from Google, Facebook, Yahoo, Twitter, 
>> etc.?
>>  
>> When working on OAuth-WRAP, I talked to all of those companies about using 
>> TLS, and only Facebook said that they wanted an option to be able to not 
>> require TLS. Since then, all Facebook's new APIs which are essentially using 
>> OAuth 2.0 run on TLS.
>>  
>>  
>>  
> 
> _______________________________________________
> 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

Reply via email to