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

John Bradley <ve7jtb@ve7jtb.com> Thu, 26 January 2012 14:11 UTC

Return-Path: <ve7jtb@ve7jtb.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 5FD9121F8630 for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2012 06:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.521
X-Spam-Level:
X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.077, 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 PDjZ4D1MyrmT for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2012 06:11:32 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54FDF21F84CE for <oauth@ietf.org>; Thu, 26 Jan 2012 06:11:32 -0800 (PST)
Received: by yenm3 with SMTP id m3so255156yen.31 for <oauth@ietf.org>; Thu, 26 Jan 2012 06:11:31 -0800 (PST)
Received: by 10.236.177.6 with SMTP id c6mr3435075yhm.42.1327587091790; Thu, 26 Jan 2012 06:11:31 -0800 (PST)
Received: from [192.168.1.210] ([190.22.77.155]) by mx.google.com with ESMTPS id d5sm11057213anm.22.2012.01.26.06.11.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 06:11:30 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_5A7D3E92-07CF-4691-A297-33612F97CA85"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4F215DEE.6020608@mitre.org>
Date: Thu, 26 Jan 2012 11:11:15 -0300
Message-Id: <C092AE39-80CE-4B39-A0B2-2AF7E3633A71@ve7jtb.com>
References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F215DEE.6020608@mitre.org>
To: Justin Richer <jricher@mitre.org>
X-Mailer: Apple Mail (2.1251.1)
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 14:11:33 -0000

Yes Justin's rewording makes it sound less like non-interoperability is a desired outcome.


On 2012-01-26, at 11:06 AM, Justin Richer wrote:

> 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.
> 
>>> Suggested non-trivial clarifications:
>>> -------------------------------------
>>> 
>>> (1) 1.3.4 - "previously arranged" might trigger discusses on the document
>>> since it implies that this spec might not be suited for broad use. I think that
>>> making it clear that the normal mode for client developers is to work against
>>> an existing service (AS and resource server) would help to clarify that such
>>> arrangements are ok here.
>> Added new 'Interoperability' section to the introduction:
>> 
>>           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 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 design with the clear expectation that future work will define
>>           prescriptive profiles and extensions necessary to achieve full web-scale
>>           interoperability.          
>> 
>> There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard.
>> 
> 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.
> 
> 
>  -- Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth