My take on this is that MUSTs MAY be ignored. ;-) To echo John's concerns here, the worst-case scenario is that client libraries implement "no SSL present" as a gentle reminder warning with a flag (possibly the default) to disable those HTTPS warnings. Clients that behave in that way should be flagged as non-compliant and publicly humiliated. If we just write SHOULD for HTTPS/secure channel support, then those clients are acting "properly."
If WRAP is aiming to just be a replacement for Cookie auth, then why don't we just add a redirection profile for issuing cookies? They work now, refreshing them is built-in, etc, etc. Instead, what we're trying to do is build something better, more secure, and more aligned with the sorts of behaviours we see and want to encourage on the web. b. On 6 April 2010 11:54, John Panzer <jpan...@google.com> wrote: > My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. E.g., > SHOULD for service providers, MUST support for clients. > Otherwise, you will end up with clients that don't support https or don't do > it properly. (E.g., don't bother to check certificates.) Which hurts > security for service providers that do want SSL. > > On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt > <tors...@lodderstedt.net> wrote: >> >> +1 for the standard should recommand HTTPS or comparable means of >> transport protection but not require it. >> >> This requirement does not result in any benefit for the specification by >> itself (e.g. simplification). Therefore, the decision to use HTTPS or any >> other means should be up to the service providers based on its security >> considerations. >> >> 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 >> >> >> _______________________________________________ >> 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
