Re: [OAUTH-WG] AD Review of -22 (part II)

Phil Hunt <phil.hunt@oracle.com> Thu, 26 January 2012 18:15 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB4021F86EB for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2012 10:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.25
X-Spam-Level:
X-Spam-Status: No, score=-8.25 tagged_above=-999 required=5 tests=[AWL=2.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNzGHeeXv09k for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2012 10:15:53 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C0D7921F86E2 for <oauth@ietf.org>; Thu, 26 Jan 2012 10:15:53 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0QIFoKJ024471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 18:15:51 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q0QIFn5I004389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 18:15:50 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q0QIFncA027664; Thu, 26 Jan 2012 12:15:49 -0600
Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jan 2012 10:15:49 -0800
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 26 Jan 2012 10:15:51 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <229C3AF7-931C-42F2-B44C-4E8593CE977C@oracle.com>
References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F215DEE.6020608@mitre.org> <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1251.1)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F219858.003D,ss=1,re=0.000,fgs=0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD Review of -22 (part II)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jan 2012 18:15:55 -0000

If an app developer writes their own client, than their OAuth code becomes bound in with the code connecting to the underlying resource API which may or may not be standardized.  Regardless the tight coupling of OAuth plus an API can only be inter-operable in that specific combination.

This will be mitigated through the eventual emergence of client toolkits which keep the resource API and the authorization API cleanly separated. This may lead to further specs and refinements to OAuth2 down the road. But we don't have enough data for that today.

IMHO I think for RESTful services, fuzzy interoperability is the nature of the technology for now because of its other benefits.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-01-26, at 9:49 AM, Eran Hammer wrote:

> 
> 
>> -----Original Message-----
>> From: Justin Richer [mailto:jricher@mitre.org]
>> Sent: Thursday, January 26, 2012 6:07 AM
>> To: Eran Hammer
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II)
>> 
>> I realize that -23 is already published with the below text, but since this is a
>> whole new section and nobody else seemed to bring it up, I wanted to make
>> sure it wasn't missed by the WG.
> 
>> I think it's a good idea to call it out, and I don't want to "sugarcoat" it either,
>> but the phrase "this specification is likely to produce a wide range of non-
>> interoperable implementations" is a bit overdramatic in its tone. Instead, I
>> think we should point to other documents that are being developed explicitly
>> along side of this, such as at the beginning of RFC2904
>> (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead:
>> 
>> OAuth 2.0 provides a rich authorization framework with well-defined security
>> properties. However, as a rich and highly extensible framework with many
>> optional components, this specification does not seek to define all
>> components needed for a fully interoperable deployment within this
>> document. Instead, this specification is intended to work with complimentary
>> documents that define token types [MAC] [Bearer], token formats [JWT]
>> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD],
>> and other considerations.
>> This protocol was designed with the clear expectation that future work will
>> define prescriptive profiles and extensions necessary to achieve full web-
>> scale interoperability.
> 
> This does sugarcoat the fact that 2.0 does not provide *any* guaranteed interoperability. The implementations I've seen so far have simply adopted a *profile* of this document along with bearer tokens. We've already seen feedback on this list where client developers were surprised and frustrated with such implementations when trying to reuse code across providers and this is only going to get more noticeable. And then of course we have the insane complexity of the over-architected solutions, adding layer after layer to solve problems that are as simple as making a parameter required and well specified.
> 
> We've also seen questions about providers looking to claim OAuth 2.0 support while maintaining all their existing architecture and security properties, seeking to push the boundaries of what is permitted by the specification. We've gone to a place where *anything* can be made to look like OAuth. We've seen implementations doing nothing but exchanging SAML assertions for JSON-formatted assertions (or other SAML assertions), without any actual resource owner participation, calling itself OAuth. And sadly, it can.
> 
> I'm against adding such a laundry list of references. I am also opposed to implying that using these extensions will achieve interoperability because they will not in their current state. The only way to achieve interoperability at this point is by getting rid of most of the optional components (removed or made required), and tightening the definition of others. Or alternatively, come out with a full blown discovery and negotiation protocol - something that would be extremely premature at this point. How can you design a good discovery/negotiation protocol before you have even a partial picture of what it is you want to discovery/negotiate.
> 
> Instead, I proposing a small tweak (marked with [[ ]]) to the language:
> 
> ---
> 1.7.  Interoperability
> 
>   OAuth 2.0 provides a rich authorization framework with well-defined
>   security properties.  However, as a rich and highly extensible
>   framework with many optional components, [[ on its own, ]] this specification is likely
>   to produce a wide range of non-interoperable implementations.  In
>   addition, this specification leaves a few required components
>   partially or fully undefined (e.g. client registration, authorization
>   server capabilities, endpoint discovery).
> 
>   This protocol was designed with the clear expectation that future work
>   will define prescriptive profiles and extensions necessary to achieve
>   full web-scale interoperability.
> ---
> 
> I can appreciate feeling a little sting from such a disclaimer but we all deserve it for failing to do our job. We took on a successful, simple, narrow, and useful protocol and turned it into mush because after more than 2 years we have failed to find common ground on almost anything that is required to achieve interoperability. Instead we now rely on popular providers such as Facebook and Twitter to set the tone for the rest of the industry, filling in the gaps.
> 
> My personal frustration is from the fact that a significant number of working group members put the interest of their corporate overlord above what is good for the web. They have aggressively promoted an agenda based on product lines already in advance stages of development and refused to compromise if that meant making changes to their products. We have produced the closest heir to WS-* I've seen in many years, and that's nothing to be proud of.
> 
> The result is pretty obvious: claiming OAuth 2.0 support or even compliance is meaningless. It's the difference between dancing the tango and dancing to rock music. One gives you a beautifully synced performance while the other put personal expression on a pedestal. Which one do you think is better for a web protocol?
> 
> It's time to own the results of our work and to clearly state that this is the best we were able to produce, and let the industry take over and solve through running code the problems we were too fragmented to solve here.
> 
> EHL
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth