A requirement for TLS on the callback would make OAuth prohibitive for many of our developers. The developers are usually volunteers and they are already donating their own resources to help a non-profit (from which US law mandates the developers cannot profit). In other cases the developers are small firms operating in developing counties where establishing and maintaing a valid certificate may still be a imperfect art.
In short, a requirement like this puts the nail in the coffin of many would-be efforts to help out. So as Dick identifies here, we have sufficient security around the authorization grant by tying it client credentials. I would thus be opposed to the term "MUST." I also think it's helpful to have the language limit the SHOULD to the non-user-agent cases. There's no reason we should suggest a callback URI designed for client-side intercept to use an HTTPS url - so this is in the spirit of Phil's response to Justin's comment on limiting the scope of SHOULD. skylar On Mar 30, 2011, at 11: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
