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

agks mehx <> Sun, 29 January 2012 12:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1672F21F8540 for <>; Sun, 29 Jan 2012 04:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eNcR-r11apaV for <>; Sun, 29 Jan 2012 04:19:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3765A21F852E for <>; Sun, 29 Jan 2012 04:19:47 -0800 (PST)
Received: by ggnq4 with SMTP id q4so1659724ggn.31 for <>; Sun, 29 Jan 2012 04:19:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gaNwb0Z2A0wifBdOKXYgzME4BeDkNLV3w+2J1AQtrGc=; b=LmrNvQibrB4DxisPDkInzGuFOaP3XAoJ3wve8ZKgNqiV/eEDuCFz776VgNHVwOZpZG rDf7y3YjG873E4nY/0YQl3qJgGrs/BnOGFCAV0ui893PX8d9+FDoTZfoFqC1A18D7TpP 2VjAzt+sKdzfBWzrHyfQmDp+3baAj/f87Pg+4=
MIME-Version: 1.0
Received: by with SMTP id u25mr20287463yhl.26.1327839586807; Sun, 29 Jan 2012 04:19:46 -0800 (PST)
Received: by with HTTP; Sun, 29 Jan 2012 04:19:46 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Sun, 29 Jan 2012 19:19:46 +0700
Message-ID: <>
From: agks mehx <>
To: Eran Hammer <>,
Content-Type: multipart/alternative; boundary="20cf305e2635e3eeef04b7a9bebb"
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: Sun, 29 Jan 2012 12:19:49 -0000

I would be unhappy if things were sugarcoated any further.  This is
definitely a rare specification where OPTIONAL parameters in the API can be
REQUIRED by a conforming implmentation (as I discussed in my note on the
scope parameter for which the proposed modification does not really change

I appreciate that there is a cautionary statement that this specification
may produce non-interoperable client / server implementations, as I
discovered upon writing my first client.

The cautionary statement would be invaluable to programmers in the wild who
are not used to the unusual semantics of this particular specification.

Hence I strongly support (if it counts) keeping the language the way Eran
Hammer has suggested.

On Fri, Jan 27, 2012 at 5:12 AM, Eran Hammer <> wrote:

> 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
> >section.
> >
> >  -- 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.
> >>
> >> EHL
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> _______________________________________________
> OAuth mailing list