[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.
- [OAUTH-WG] Proposed change to section 8.4. Defini… Eran Hammer-Lahav
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Aiden Bell
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Mike Jones
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Eran Hammer-Lahav
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Eran Hammer-Lahav
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Mike Jones
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Aiden Bell
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Breno
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Eran Hammer-Lahav
- Re: [OAUTH-WG] Proposed change to section 8.4. De… Barry Leiba