Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 19 July 2011 16:25 UTC

Return-Path: <eran@hueniverse.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 148E21F0C3B for <oauth@ietfa.amsl.com>; Tue, 19 Jul 2011 09:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o25AmF0PInzW for <oauth@ietfa.amsl.com>; Tue, 19 Jul 2011 09:24:59 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3103F1F0C37 for <oauth@ietf.org>; Tue, 19 Jul 2011 09:24:59 -0700 (PDT)
Received: (qmail 15843 invoked from network); 19 Jul 2011 16:24:58 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 16:24:58 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 19 Jul 2011 09:24:51 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Tue, 19 Jul 2011 09:24:27 -0700
Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zgAVXKWw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
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: Tue, 19 Jul 2011 16:25:00 -0000

Revised text. I changed it to focus on the implementation details.

In other words, all response types must be registered. If the type name includes spaces, it changes how the value is compared (space-delimited list of values where the order does not matter). That's it. Spaces only change how values are compared.

EHL

---

8.4.  Defining New Authorization Endpoint Response Types

   New response types for use with the authorization endpoint are
   defined and registered in the authorization endpoint response type
   registry following the procedure in Section 11.3.  Response type
   names MUST conform to the response-type ABNF.

     response-type  = response-name *( SP response-name )
     response-name  = 1*response-char
     response-char  = "_" / DIGIT / ALPHA

   If a response type contains one of more space characters (%x20), it is
   compared as a space-delimited list of values in which the order of values
   does not matter. Only one order of values can be registered, which covers
   all other arrangements of the same set of values.

   For example, the response type "token code" is left undefined by this specification.
   However, an extension can define and register the "token code" response type.
   Once registered, the same combination cannot be registered as "code token", but
   both values can be used to denote the same response type.

Also, change the definition of response_type in section 3.1.1:

   response_type
         REQUIRED.  The value MUST be one of "code" for requesting an
         authorization code as described by Section 4.1.1, "token" for
         requesting an access token (implicit grant) as described by
         Section 4.2.1, or a registered extension value as described by
         Section 8.4. If the response type contains one or more space characters
         (%x20), it is interpreted as a space-delimited list of values, where
         the order of values does not matter (e.g. "a b" is the same as "b a").