Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

Marius Scurtescu <mscurtescu@google.com> Mon, 10 May 2010 20:28 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 52A3B3A6C25 for <oauth@core3.amsl.com>; Mon, 10 May 2010 13:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.783
X-Spam-Level:
X-Spam-Status: No, score=-100.783 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 CLWo19V48IX2 for <oauth@core3.amsl.com>; Mon, 10 May 2010 13:28:53 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9A0FD3A6823 for <oauth@ietf.org>; Mon, 10 May 2010 13:16:40 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4AKGSHV032766 for <oauth@ietf.org>; Mon, 10 May 2010 13:16:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273522588; bh=pXpJh4s94pSMpayv/UpJW3dT2m8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=l0zPgGuRuxM9htilJ3N2SZ+IjLzIWEV/xQJvExl6JgtzhBNTqmp8VRvrSBVTDA32C ZDxGqp9/oQd23MW5t5SLA==
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=SrbFs7lttcJQ3Xt9B2uRO7DrtBtNirLt0A9Lv+XhHX9ten98bWN65j9O1AagN0A53 Gu7dPEmCIdIkCIW/U5rIA==
Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by wpaz21.hot.corp.google.com with ESMTP id o4AKGQ5s017833 for <oauth@ietf.org>; Mon, 10 May 2010 13:16:26 -0700
Received: by pxi1 with SMTP id 1so1732336pxi.36 for <oauth@ietf.org>; Mon, 10 May 2010 13:16:26 -0700 (PDT)
Received: by 10.141.187.25 with SMTP id o25mr2901009rvp.71.1273522586129; Mon, 10 May 2010 13:16:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 13:16:06 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 10 May 2010 13:16:06 -0700
Message-ID: <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.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)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
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, 10 May 2010 20:28:54 -0000

On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>
>> -----Original Message-----
>> From: Dick Hardt [mailto:dick.hardt@gmail.com]
>> Sent: Sunday, May 09, 2010 5:52 PM
>
>> >> 3.5.1.  Client Requests Authorization
>> >>
>> >> If the client has previously registered a redirection URI with the
>> >>    authorization server, the authorization server MUST verify that the
>> >>    redirection URI received matches the registered URI associated with
>> >>    the client identifier.
>> >>
>> >> Does this mean equality? Or just the same base string?
>> >
>> > Right now it depends on the server.
>>
>> The spec should clarify that. Suggested wording:
>>
>>
>> If the client has previously registered a redirection URI with the authorization
>> server, the authorization server MUST verify that the redirection URI
>> received matches the registered URI associated with the client identifier. The
>> components of the redirection URI that must match the registered URI is
>> authorization server dependant.
>
> I don't see how that helps... I also don't see why we can't just profile this and decide on how the matching should be done. We have the state parameter to help too.

I also think the spec should specify how the matching should be done.

If left up to the authz server then a client that designs its OAuth 2
implementation will have to assume that all authz servers will do
strict equality matching, otherwise it may not be able to interact
with some servers.

For example, if the client assumes that it can use load balancing by
varying the first part of the host name, and this may work with the
fist authz server it integrate with, later this client will not be
able to interact with an authz server which does strict matching on
host name. And changing the load balancing architecture once deployed
could be very hard.

Since there is a state parameter maybe it is enough to allow wild
cards only in the domain name of the callback URI.

Marius