++
Igor
Torsten Lodderstedt wrote:
Hi Blaine,
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
I don't understand your objections. If a resource provider decides to
support HTTPS only, no client w/o HTTPS support can connect thus
circumventing this policy.
that behave in that way should be flagged as non-compliant and
publicly humiliated.
agreed :-)
If we just write SHOULD for HTTPS/secure channel
support, then those clients are acting "properly."
Why not explicitly state in the spec that HTTPS support is a MUST HAVE
for libraries?
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.
There are a variety of deployment scenarios for OAuth2 (e.g. internet
small/large, intranet) as well as replay countermeasures (encryption,
short-living tokens, restricted permissions, ...). Can we really
anticipate/consider all of them and select HTTPS as the only solution?
Even the spec for BASIC-Authentication
(http://www.ietf.org/rfc/rfc2617.txt) does not force a certain mean of
transport protection. It just recommends to consider security
enhancements:
---- from http://www.ietf.org/rfc/rfc2617.txt
The Basic authentication scheme is not a secure method of user
authentication, nor does it in any way protect the entity, which is
transmitted in cleartext across the physical network used as the
carrier. HTTP does not prevent additional authentication schemes and
encryption mechanisms from being employed to increase security or the
addition of enhancements (such as schemes to use one-time passwords)
to Basic authentication.
The most serious flaw in Basic authentication is that it results in
the essentially cleartext transmission of the user's password over
the physical network. It is this problem which Digest Authentication
attempts to address.
Because Basic authentication involves the cleartext transmission of
passwords it SHOULD NOT be used (without enhancements) to protect
sensitive or valuable information.
----
HTTPS is state of the art and should from in my opinion be the
_recommended_ option. This leaves implementors enough freedom to use
other security measures where neccessary/sufficient/applicable.
regards,
Torsten.
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
_______________________________________________
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
