IETF Logo Mail Archive

Re: [OAUTH-WG] Strict equality matching of redirect_uri

Dick Hardt <dick.hardt@gmail.com> Sun, 16 May 2010 18:20 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 CE89B3A6BA5 for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level:
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001]
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 i7R1u+VrRX-x for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:20:50 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E73013A6B9C for <oauth@ietf.org>; Sun, 16 May 2010 11:20:40 -0700 (PDT)
Received: by pvg11 with SMTP id 11so1403663pvg.31 for <oauth@ietf.org>; Sun, 16 May 2010 11:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pSXG5WArcqjcMQLveb614wNd+UrVnUxbd4D6a7qTpDU=; b=QSunmab7URi8eA9PEHhAB0BFNFKLDKa9+77HtGSDwB+xZYWHUz0g8/Yc+ct/uBEMOA 3fRB8b2oxARtSxaDmgOE+UHgFcSRqYKhqlckQD0ZfC/im79vZFflVHBpFfVG4a1o+bUq EicFDfggJ7GdQMyuk1lfrcr8q/Kq3kIRk+Gcs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=D2KrIoARCs0joGbT9wBSlfb8QxSPhFaxLzdv84m6Pismi03PZy7yewb7sZ+gg0b1/A vjs3TSt9wxxCd98WjwUYVbmNvBmj0PGK1um42MfZgMSnJ5gtUmq6rqkYfpdj37DTmd6v 9YSL/MdKwB0hte2gEmYnzptvOBbSjs/zHmzII=
MIME-Version: 1.0
Received: by 10.142.74.19 with SMTP id w19mr2660290wfa.20.1274034029689; Sun, 16 May 2010 11:20:29 -0700 (PDT)
Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 11:20:29 -0700 (PDT)
In-Reply-To: <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com>
References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com>
Date: Sun, 16 May 2010 11:20:29 -0700
Message-ID: <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
To: Luke Shepard <lshepard@facebook.com>, Allen Tom <atom@yahoo-inc.com>, Brian Eaton <beaton@google.com>
Content-Type: multipart/alternative; boundary="001636d34bfec57b490486ba29c4"
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri
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: Sun, 16 May 2010 18:20:55 -0000

On Tue, May 11, 2010 at 11:31 PM, Luke Shepard <lshepard@facebook.com>wrote:

> FWIW, Facebook does not do strict equality matching on redirect_uri. We
> accept any redirect_uri that has either:
>
> - its prefix is the registered url
> - or it is a special facebook.com/xd_proxy.php url, with an origin
> parameter that has a prefix on the registered url
>
> I think that the spec should leave the matching up to the server.


If the matching is left to an arbitrary, server defined algorithm, we lose
interop since a client implementation may make assumptions on what may be
allowed in the redirect_uri at one AS and then not be able to work with
another AS that is more restrictive.

As this is a security feature, I'd like to hear the options from the
security oriented participants with experience here.

Allen / Brian?

v2.23.0 | Report a Bug | By Email