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

Justin Richer <> Thu, 26 January 2012 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A45921F85C3 for <>; Thu, 26 Jan 2012 13:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JipcZqcNI+kX for <>; Thu, 26 Jan 2012 13:22:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2C63921F8486 for <>; Thu, 26 Jan 2012 13:22:15 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 12ADD21B194E; Thu, 26 Jan 2012 16:22:14 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG ( []) by (Postfix) with ESMTP id EBA4321B18B9; Thu, 26 Jan 2012 16:22:13 -0500 (EST)
Received: from [] ( by IMCCAS01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 16:22:13 -0500
Message-ID: <>
Date: Thu, 26 Jan 2012 16:21:08 -0500
From: Justin Richer <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Eran Hammer <>
References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB969E8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] AD Review of -22 (part II)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2012 21:22:16 -0000

I really don't see it this way, as a failure. Instead, I think we've 
managed to successfully scope the document to address important 
practices and bits of the protocol that will work in tandem with other 
documents to solve different use cases. One of the biggest problems that 
we saw coming in from OAuth1.0 was that it tried to be all things to all 
people all at once, which also didn't help interoperability. I think 
that what we have is a more composable UNIXy approach here. Namely, 
OAuth 2 core/framework/whatever does one thing and does it well: it 
outlines a standard means and structure for getting a token. Does that 
help you use the token against a web service, do service discovery, pack 
information into the token itself? No, but it wasn't meant to. It was 
meant to leave enough space for other docs to take care of that.

But I do not think that it's gone so far as to leave a morass of 
unusable components, much in the way that WS-* did, and I don't think 
the comparison is a fair one. I think the separations are clean and the 
usage profiles are clear.

By pointing developers to other specifications, most of which are 
products of this very working group or members of this working group 
under other umbrellas, we *can* provide a wider view of the world. At 
the absolute least, I think it needs to point to the two token type 
docs, and I'd suggest at least keeping the two token format docs as 
well. And as was pointed out by Phil Hunt, this notion of loosely 
coupled specs and components is actually *beneficial* to today's web 
environment. This is another way that this work differs from WS-*: if 
you're doing one part of WS-*, you're not going to get away without 
doing the rest of it too if you want to have a working system. As you 
point out, and somewhat lament, this is not the case with OAuth 2. You 
can do some parts, and not others, and utalize just the bits that you 
need. The fact that I can use the same endpoints and mechanisms for 
user-delegated auth and machine-directed auth is very powerful, and the 
fact that I can use the same exact client libraries to fetch and use 
both random-hex tokens and signed JWTs is equally powerful. The fact 
that I can reuse 90% of that code and also get signed MAC tokens is 
likewise powerful.

Thus, I stand by my originally-suggested text and respectfully submit it 
to the editor and working group for consideration of inclusion in this 

  -- Justin

On 01/26/2012 12:49 PM, Eran Hammer wrote:
>> -----Original Message-----
>> From: Justin Richer []
>> 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
>> ( 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.