Phil I'd suggest you review the spec so that you understand what Eran and I are saying. No code has been granted in the redirect to a web client, where implementing TLS server side is a major barrier.
-- Dick On 2011-03-30, at 9:15 AM, Phil Hunt wrote: > 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
