Re: [OAUTH-WG] OAuth 2.0: client_secret, state
Marius Scurtescu <mscurtescu@google.com> Thu, 25 March 2010 22:23 UTC
Return-Path: <mscurtescu@google.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 00FAD3A6C94 for <oauth@core3.amsl.com>; Thu, 25 Mar 2010 15:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.247
X-Spam-Level:
X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1LoPfNlDI-Jf for <oauth@core3.amsl.com>; Thu, 25 Mar 2010 15:23:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 745563A6BAF for <oauth@ietf.org>; Thu, 25 Mar 2010 15:23:35 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [10.3.21.2]) by smtp-out.google.com with ESMTP id o2PMNrTf028111 for <oauth@ietf.org>; Thu, 25 Mar 2010 15:23:53 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1269555834; bh=tuusc2Tjo2yGjP+x1PDk+xnFcu8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=lQ738IM2R7wJ8TFiqLvilxjlF+QlIZ4jjiY4Gva0Xf7Xu8l4rR3ts7Wmv79Zj3mko ZUFPJqWN49H6XbOqIp5Aw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=gu6f8aFGkLSOsm+gd65uKFqcETy85D2zZWea7n51ew7dcjHsDeBuTRnF/9NEx6OnT 47dK3CG+kM9Wq64H8/9+w==
Received: from fg-out-1718.google.com (fgad23.prod.google.com [10.86.55.23]) by hpaq2.eem.corp.google.com with ESMTP id o2PMNow5029859 for <oauth@ietf.org>; Thu, 25 Mar 2010 23:23:52 +0100
Received: by fg-out-1718.google.com with SMTP id d23so2298947fga.7 for <oauth@ietf.org>; Thu, 25 Mar 2010 15:23:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.125.13 with SMTP id c13mr995630mun.81.1269555829682; Thu, 25 Mar 2010 15:23:49 -0700 (PDT)
In-Reply-To: <fd6741651003221052x357eb64fj2ffc1544650b9599@mail.gmail.com>
References: <526C3C44-18CF-4A94-A4C6-72702F73AC83@facebook.com> <255B9BB34FB7D647A506DC292726F6E112531C851D@WSMSG3153V.srv.dir.telstra.com> <fd6741651003221052x357eb64fj2ffc1544650b9599@mail.gmail.com>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Thu, 25 Mar 2010 18:23:29 -0400
Message-ID: <74caaad21003251523p4dac2a5en6c4e3ae3f14e4ea@mail.gmail.com>
To: David Recordon <recordond@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0: client_secret, state
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: Thu, 25 Mar 2010 22:23:49 -0000
On Mon, Mar 22, 2010 at 1:52 PM, David Recordon <recordond@gmail.com> wrote: > On Mon, Mar 22, 2010 at 5:11 AM, Manger, James H > <James.H.Manger@team.telstra.com> wrote: >> 2. STATE >> OAuth has various parameter that are used to carry state for another party in a message, which is helpful for building scalable systems. OAuth should avoid duplicating these fields or defining their semantics when they are opaque to the party carrying them. This will keep the protocol simpler, without losing any functionality. >> >> oauth_client_state is unnecessary as it is always accompanied by oauth_callback_url that can encode the state directly. The examples could include, say, ...callback_url=http://client.example.com/cb%3Fstate=FSR63fs&oauth_mode=... to reflect likely cases. It is still simple to compare the callback to a pre-register value if required (eg compare suffix, or compare ignoring additional query params). > > Has there been any discussion of the oauth_client_state parameter on > the list? I don't really remember it. Not sure if this was discussed or not, but I think client state can be really useful. Yes, client state can be added to the callback URL, but this makes validating this URL against a registered callback URL more difficult. This ties in with the fact that the validation of these URLs is not specified. It is easy to imagine an Authorization Server that does strict validation of callback URLs, in which case the only way to pass client state through is with this extra parameter. Marius
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Richard Barnes
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 John Panzer
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- [OAUTH-WG] OAuth 2.0: client_secret, state Manger, James H
- Re: [OAUTH-WG] First draft of OAuth 2.0 Manger, James H
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Luke Shepard
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state David Recordon
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Manger, James H
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Allen Tom
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state David Recordon
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Richard Barnes
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- Re: [OAUTH-WG] First draft of OAuth 2.0 Mark Mcgloin
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] First draft of OAuth 2.0 John Panzer
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Paul Madsen
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Allen Tom
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Brian Eaton
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 David Recordon
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Anthony Nadalin
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Dick Hardt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Torsten Lodderstedt
- Re: [OAUTH-WG] First draft of OAuth 2.0 Chuck Mortimore
- Re: [OAUTH-WG] First draft of OAuth 2.0 Anthony Nadalin
- Re: [OAUTH-WG] First draft of OAuth 2.0 Hans Granqvist
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] First draft of OAuth 2.0 Eve Maler
- Re: [OAUTH-WG] OAuth 2.0: client_secret, state Marius Scurtescu