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

Eran Hammer <> Thu, 26 January 2012 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBE4221F8663 for <>; Thu, 26 Jan 2012 14:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NmoBdlzq-YPN for <>; Thu, 26 Jan 2012 14:16:54 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 69AF921F85E0 for <>; Thu, 26 Jan 2012 14:16:54 -0800 (PST)
Received: (qmail 28659 invoked from network); 26 Jan 2012 22:13:03 -0000
Received: from unknown (HELO ( by with SMTP; 26 Jan 2012 22:13:02 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([]) with mapi; Thu, 26 Jan 2012 15:12:47 -0700
From: Eran Hammer <>
To: Justin Richer <>
Date: Thu, 26 Jan 2012 15:12:44 -0700
Thread-Topic: [OAUTH-WG] AD Review of -22 (part II)
Thread-Index: Aczcd6LFxrbFUD1SSmmYLTf9LQ8B6g==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 22:16:56 -0000

The specification already has informative references to the two token
types. From purely practical standpoint, I am not adding any more
references because that creates more dependencies and longer wait time.

There is nothing factually incorrect about the current text. It already
makes it clear that additional work is required and expected. It is also a
fact that it will produce a wide range an non-interoperable
implementations unlike, say, HTTP. We have to make this clear to the
reader upfront because every reader outside this WG has exactly the
opposite expectation, especially coming from 1.0.

I'll make the small tweak proposed below before this goes to the RFC
editor, but am not making any other changes to the text unless you can
show it is factually incorrect or incomplete.


On 1/26/12 1:21 PM, "Justin Richer" <> wrote:

>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
>>> 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
>>> 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
>>> properties. However, as a rich and highly extensible framework with
>>> 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
>>> documents that define token types [MAC] [Bearer], token formats [JWT]
>>> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD]
>>> and other considerations.
>>> This protocol was designed with the clear expectation that future work
>>> define prescriptive profiles and extensions necessary to achieve full
>>> 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
>> 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,
>>     server capabilities, endpoint discovery).
>>     This protocol was designed with the clear expectation that future
>>     will define prescriptive profiles and extensions necessary to
>>     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
>> EHL