Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

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 <bburke@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