My comments are not motivated in any way by my employer. The probably wish like you I would drop it.
I am simply reporting what I see in the wild. Phil > On Jul 24, 2014, at 12:47, Bill Burke <bbu...@redhat.com> wrote: > > > >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
