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

Justin Richer <jricher@mitre.org> Thu, 26 January 2012 14:07 UTC

Return-Path: <jricher@mitre.org>
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 6DEC921F8667 for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2012 06:07:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Sy2rM8iRiIew for <oauth@ietfa.amsl.com>; Thu, 26 Jan 2012 06:07:45 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 63B5D21F8649 for <oauth@ietf.org>; Thu, 26 Jan 2012 06:07:45 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B5F8421B08C6; Thu, 26 Jan 2012 09:07:44 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8105521B1598; Thu, 26 Jan 2012 09:07:44 -0500 (EST)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 09:07:44 -0500
Message-ID: <4F215DEE.6020608@mitre.org>
Date: Thu, 26 Jan 2012 09:06:38 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Eran Hammer <eran@hueniverse.com>
References: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB96544@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------040904020605070505090400"
X-Originating-IP: [129.83.31.51]
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:07:46 -0000

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