Re: [OAUTH-WG] AD Review of -22 (part II)
agks mehx <agksmehx@gmail.com> Sun, 29 January 2012 12:19 UTC
Return-Path: <agksmehx@gmail.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 1672F21F8540 for <oauth@ietfa.amsl.com>; Sun, 29 Jan 2012 04:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNcR-r11apaV for <oauth@ietfa.amsl.com>; Sun, 29 Jan 2012 04:19:47 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3765A21F852E for <oauth@ietf.org>; Sun, 29 Jan 2012 04:19:47 -0800 (PST)
Received: by ggnq4 with SMTP id q4so1659724ggn.31 for <oauth@ietf.org>; Sun, 29 Jan 2012 04:19:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.236.173.37 with SMTP id u25mr20287463yhl.26.1327839586807; Sun, 29 Jan 2012 04:19:46 -0800 (PST)
Received: by 10.236.154.73 with HTTP; Sun, 29 Jan 2012 04:19:46 -0800 (PST)
In-Reply-To: <CB470E62.10014%eran@hueniverse.com>
References: <4F21C3C4.7060607@mitre.org> <CB470E62.10014%eran@hueniverse.com>
Date: Sun, 29 Jan 2012 19:19:46 +0700
Message-ID: <CAG+j4Tp-=TAr29-QznuMrkk3gK4ZnMxp+jfXkey7X3+7y0qB7A@mail.gmail.com>
From: agks mehx <agksmehx@gmail.com>
To: Eran Hammer <eran@hueniverse.com>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="20cf305e2635e3eeef04b7a9bebb"
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: 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 much) 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 <eran@hueniverse.com> 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. > > EHL > > > > On 1/26/12 1:21 PM, "Justin Richer" <jricher@mitre.org> 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 [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 >
- Re: [OAUTH-WG] AD Review of -22 (part II) Stephen Farrell
- Re: [OAUTH-WG] AD Review of -22 (part II) Eran Hammer
- Re: [OAUTH-WG] AD Review of -22 (part II) Justin Richer
- Re: [OAUTH-WG] AD Review of -22 (part II) John Bradley
- Re: [OAUTH-WG] AD Review of -22 (part II) Eran Hammer
- Re: [OAUTH-WG] AD Review of -22 (part II) Phil Hunt
- Re: [OAUTH-WG] AD Review of -22 (part II) Justin Richer
- Re: [OAUTH-WG] AD Review of -22 (part II) Eran Hammer
- Re: [OAUTH-WG] AD Review of -22 (part II) agks mehx