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
