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

Bill Burke <bburke@redhat.com> Thu, 24 July 2014 16:47 UTC

Return-Path: <bburke@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B67F1A0439 for <oauth@ietfa.amsl.com>; Thu, 24 Jul 2014 09:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZVY55pvyBIq for <oauth@ietfa.amsl.com>; Thu, 24 Jul 2014 09:47:26 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236BD1A0176 for <oauth@ietf.org>; Thu, 24 Jul 2014 09:47:20 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6OGlJHp027791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <oauth@ietf.org>; Thu, 24 Jul 2014 12:47:19 -0400
Received: from [10.10.53.242] (vpn-53-242.rdu2.redhat.com [10.10.53.242]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6OGlIgL024824 for <oauth@ietf.org>; Thu, 24 Jul 2014 12:47:18 -0400
Message-ID: <53D13898.9060701@redhat.com>
Date: Thu, 24 Jul 2014 12:47:20 -0400
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <CABzCy2Ar_pJt30ctP6hQ47rpSUGMh-+rrYssWe+XFNY73dA_YQ@mail.gmail.com> <CAEayHENLvazYAcu==_3CM9x91DDqhHngtSarm4_qBu5Zf_-ipw@mail.gmail.com> <CAEayHENtujNPbVFYjO3iCN43R! V3AWdxKFrX4qhDgMwKz6VtGhw@mail.gmail.com> <B3031E2C-8F1E-4DEC-B739-2F2FFC349D39@lodderstedt.net> <B86C4C6C-AC24-45DF-A3B4-F8D1A88BC64A@ve7jtb.com> <d4b20f338a298530b4a3430386502d25@lodderstedt.net> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> <CABzCy2Dmms4MGTsuQkzu3uQGChLtNDKQREo1_S7UwfaW3hQnqA@mail.gmail.com> <CA+k3eCSiwB3pC5j+zFgrLHg7DdnWMjdJ7VVfY=NWbeY-3ndoyA@mail.gmail.com> <9dbf8c7384e341a08334a9ee093697f8@BLUPR03MB309.namprd03.prod.outlook.com> <CA+k3eCTFpOyM78r7NAY=LVbYgdYC5dXUP4ej9i1ZUT6m_rO8PQ@mail.gmail.com> <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com>
In-Reply-To: <45D858DE-6F5E-46D4-828C-9C4C80C3AC2A@oracle.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pOfHs6SeWRIE3hlomplZYrGm__s
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 16:47:29 -0000


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