IETF Logo Mail Archive

Re: [OAUTH-WG] Issue: state in web server flow

Dick Hardt <dick.hardt@gmail.com> Mon, 19 April 2010 05:36 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C923A6AAD for <oauth@core3.amsl.com>; Sun, 18 Apr 2010 22:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.409
X-Spam-Level:
X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a3zaAl4ZziI for <oauth@core3.amsl.com>; Sun, 18 Apr 2010 22:36:15 -0700 (PDT)
Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 7D2973A6AA8 for <oauth@ietf.org>; Sun, 18 Apr 2010 22:36:15 -0700 (PDT)
Received: by ywh38 with SMTP id 38so2427595ywh.29 for <oauth@ietf.org>; Sun, 18 Apr 2010 22:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=p9Q3MTBK9o34EWb92BMCGxTYWKOyfGlAxddhFp19+Bg=; b=GKOmeDJ0NIIWh5tln5YAbd9ZW4QCTifAvn+20/hGwjBusL4sydncxlikwFJz703pQu r+LYK5wok4nnTzIYy5EcI8m0VXOcaDLsOJRALuizhmGh4OTeeD9BU6nMH8eAyvq+7MbO 3tmrXtbk3DrJxBozglXOub4TA30pfXMZsfyeo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nQr/1O7rNID1YhWOT1U/4J66awp2fwvnc+hmwobg3n3KxAnf9z09iYv1GsRLpdov3M VpqCdINcVqJw83qI9tW7X2tAQfwd+I54KsSiPdqejzq0g8dmpzSPhk1UujL5D2Jf4n7b ozxmSe6JJFnpSJItqRXJDdWdJlzXlBU4XZ6kg=
Received: by 10.101.27.3 with SMTP id e3mr12498046anj.123.1271655363550; Sun, 18 Apr 2010 22:36:03 -0700 (PDT)
Received: from [10.0.1.4] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id y2sm42115592ani.14.2010.04.18.22.36.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Apr 2010 22:36:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E30A379E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sun, 18 Apr 2010 22:36:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4776FFF7-45E6-4945-9548-382A9DB84A95@gmail.com>
References: <1E39CE38-763E-4E3D-96D4-DC757BD53B9D@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1078)
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: state in web server flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 19 Apr 2010 05:36:16 -0000

On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote:

> 
> 
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Dick Hardt
>> Sent: Sunday, April 18, 2010 9:20 PM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Issue: state in web server flow
>> 
>> Why was the state parameter removed from the web server flow?
> 
> I didn't want to both define a state parameter *and* allow for any other client-specific parameters in redirection URIs. Because people made the point that *any* client-specific parameters are required, I proposed to drop the state parameter. After all, servers MUST send back whatever URI they receive regardless of it being encoded into a state parameter.
> 
>> Some AS may require the entire redirect URI to be registered, so the state
>> parameter allows a client to maintain state across calls.
> 
> I agree that this is useful, but it only makes the spec better if we make its use more restrictive. Defining it makes it easier for servers to validate the redirection URI, but only if the client is not allowed using other client-specific query parameters with it.

Agreed

> 
> If people feel strongly about putting it back, I suggest we only allow it with callbacks without any query component as that is the only combination it adds value.

Agreed

v2.23.0 | Report a Bug | By Email