On 7/24/2014 10:30 AM, Phil Hunt wrote:
Horseshit.
Horseshit to your horseshit.
Ian failed to mention that we’re responding to bad use of 6749 by
assuming receipt of access token == authentication.
The OAuth WG is not creating a new feature and we are not re-inventing
here. If anyone is, one could argue that would be OpenID —> at least in
the minds of the web developers. They don’t get why they have to use
OpenID at all. Doesn’t OAuth already do this???
Maybe from your perspective. From my perspective in the Java community
at least, security for REST services is a cluster fuck. Developers in
the Java community are looking for answers. For most of them, security
is an afterthought done at the last minute. They think OAuth will solve
their RESTful security issues only to find that OAuth is just a
framework not a protocol and delegates many difficult issues to
underlying implementations.
The working group is responding to an issue that the market has ALREADY
chosen to do all by itself without the presence of any additional
specification like A4C or for that matter OpenID.
The market is doing this because_ they are under the false assumption
that OAuth is doing authentication_ and that receipt of the access token
IS authentication. It is unbelievable how many developers think OAuth
stands for Open Authentication. The specifications are clear. Yet, the
problem persists.
If a developer already thinks they have a solution that is good enough,
why would they go to another standards organization? They aren’t even
looking for an OpenID. They think they already have THE solution! Which
is precisely why OpenID can’t address the issue by itself! OpenID as an
authenticator *is* re-invenention. Yes, OpenID as an IDP provider
standard is its own innovation (re-inventing SAML and many many other
protocols of the past), but within the realm of OAuth, yes it is
innovation in my opinion..
Ridiculous statements. How does anything above justify the existence of
A4C. If developers already have their solutions, why would they give a
shit about A4C?
But keep in mind that these developers do NOT want an IDP architecture.
Says who? You? And what does an IDP architecture have to do with Open
ID Connect or its use with OIDC? You can still use a vanilla OAuth2
client library with an IDP that implements Open ID Connect.
My point in producing the original draft was to show how simple the
correction could be — a few pages of clarifying text.
Since OpenID has been proposed as the simple solution, let me point out
why it is not for these developers: it is a specification that
incredibly complicates OAuth:
* OpenID adds 6 response types to OAuth’s 2
* OpenID adds 6 errors to OAuth’s 4
* OpenID doubles the number of parameters
* OpenID’s core specification is approximately NINETY THREE pages to
6749’s 76 pages
Like many have said over and over, A4C is already covered by OpenID.
The subset of A4C is already legal under OpenID.
Besides, you actually think web developers care about reading some IETF
specification? From my 20+ years of developing middleware, developers
do not read specifications! They read the documentation and examples of
the frameworks that implement these specifications.
I’m not at all saying that OpenID is bad. If you want an IDP, its fine.
But if all a client wants is authentication, they think why can’t I
just use RFC6749?
Yup. Like I said before. If the IDP implements OpenID Connect, there
is nothing stopping a client just using vanilla OAuth.
The people in the CIS audience were not aware of the facts, so of
course, they cheered against what appears to be a fork. That’s after all
how it was presented. In fact, Ian’s presentation sounds horribly
trivial and insensitive in its handling of this case.
The point is, NOT responding to this issue does not mean it goes away.
It gets worse. The market is already choosing to use OAuth for
authentication.
And OpenID Connect is OAUTH!
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
