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

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 19 July 2011 06:22 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 96FD121F8663 for <oauth@ietfa.amsl.com>; Mon, 18 Jul 2011 23:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 mS+bB8juP03Y for <oauth@ietfa.amsl.com>; Mon, 18 Jul 2011 23:22:14 -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 D54AA21F8589 for <oauth@ietf.org>; Mon, 18 Jul 2011 23:22:13 -0700 (PDT)
Received: (qmail 26772 invoked from network); 19 Jul 2011 06:22:12 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jul 2011 06:22:12 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 18 Jul 2011 23:22:12 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Mon, 18 Jul 2011 23:21:49 -0700
Thread-Topic: Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zg==
Message-ID: <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: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234501D6E0653P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [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 06:22:15 -0000

I have tried to accommodate both the use cases and concerns raised. The new text allows the registration of composite response types in which the order of the space-delimited values does not matter. However, every combination must be registered in order to avoid developers guessing what an unregistered combination might mean.

Feedback requested.

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

   The space character (%x20) is reserved for defining composite response types.
  Each composite response types MUST be registered, even if each of its components
   are individually registered. The order of components in a composite response type
   does not matter. The meaning of unregistered composite response types made up of
   individually registered values is undefined.

   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 make an authorization request, and refer to 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. A value containing one or more space characters (%x25)
         identifies a composite response type in which the order of the
         space-delimited sub-values does not matter.