Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
Mike Jones <Michael.Jones@microsoft.com> Tue, 19 July 2011 16:33 UTC
Return-Path: <Michael.Jones@microsoft.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 890CF1F0C3B for <oauth@ietfa.amsl.com>; Tue, 19 Jul 2011 09:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.463
X-Spam-Level:
X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 rxWPLfPFiP-t for <oauth@ietfa.amsl.com>; Tue, 19 Jul 2011 09:33:45 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52F1F0C37 for <oauth@ietf.org>; Tue, 19 Jul 2011 09:33:37 -0700 (PDT)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Jul 2011 09:33:36 -0700
Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.198]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0323.002; Tue, 19 Jul 2011 09:33:36 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
Thread-Index: AcxF2IFuXcht7wZvT3mPDMC79ij6zgAVXKWwAADpQAA=
Date: Tue, 19 Jul 2011 16:33:35 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394348D52D1F@TK5EX14MBXC201.redmond.corp.microsoft.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0653@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D6E0720@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.35]
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:33:45 -0000
Good -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 19, 2011 9:24 AM To: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types 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"). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [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