Hi Tony, I¹m suggesting that the Service Provider determine whether its services are available via HTTPS, HTTP, or both.
This is exactly how it is today. AFAIK, there are no standard interoperable APIs that use Oauth. All (or practically all) APIs that use Oauth are completely proprietary. For proprietary interfaces, it¹s really up to the Service Provider to determine if their data and services are valuable enough to justify using HTTPs. (I personally think that everything should use HTTPS, however I don¹t think that Service Providers should be required to implement HTTPS if they don¹t think their proprietary API requires it) I do hope that there are standard interoperable interfaces that are built on top of OAuth2 however it¹s up to the authors of these interfaces to determine whether SSL is required or not. The issue with specifying whether the SP should require HTTPS is very similar to the problem with specifying how the the user authenticates with the SP. Should the user have a strong password? Should the SP implement CAPTCHA or other anti-password cracking mechanisms? Maybe users should have multi-factor auth? I recommend that the spec does not require HTTPS this decision is really up to the Service Provider if they¹re providing a proprietary interface. Future standard interfaces that are built on top of Oauth should determine for themselves whether or not HTTPS is required. Allen On 4/6/10 12:50 PM, "Anthony Nadalin" <tony...@microsoft.com> wrote: > I¹m not sure if you are coming from the user or service perspective. So if a > user asks for HTTPS do you have to support HTTPS? If a service asks for HTTPS > do you have to support it? Or do you just fail? > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Allen Tom > Sent: Tuesday, April 06, 2010 11:27 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] HTTPS requirement for using an Access Token without > signatures > > One of the biggest differences between OAuth2 and WRAP is that OAuth2 requires > that Protected Resources be accessed using HTTPS if no signature is being > used. Bullet Point #2 in Section 1.2 says: > > 4. Don't allow bearer tokens without either SSL and/or signatures. > While some providers may offer this ability, they should be out > of spec for doing so though technically it won't break the flows. > > While I personally think that requiring SSL is a fantastic idea, and it¹s very > hard for me to argue against it, however.... > > One of the goals for WRAP was to define a standard AuthZ interface for APIs > which matched what we currently have on the Web. WRAP protected APIs are > intended to be a replacement for screen scraping. > > On the web, almost all websites implement Cookie Auth. Specifically, when you > log into a website, the browser is issued a bearer token, called a Cookie, and > the browser is able to access Protected Resources by using the Cookie as the > credential. > > The WRAP access token is intended to be a direct replacement for the HTTP > Cookie. A client should be able to present its bearer token (a WRAP Access > Token or an HTTP Cookie) without having to sign the request. > > While I certainly think that requiring SSL would be a huge improvement in > internet security, HTTP does not require SSL, and since WRAP was intended to > be a replacement for HTTP Cookie Auth, then OAuth2 should also not require > HTTPS. > > Yes, dropping the SSL requirement isn¹t optimal, but again the intent with > WRAP was to replace HTTP Cookie auth, and it should be up to the service > provider to require HTTPS when applicable. > > Allen >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
