Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143721AD05D for ; Sat, 16 May 2015 00:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o09Bf7CY-X9N for ; Sat, 16 May 2015 00:43:27 -0700 (PDT) Received: from mail.dynms.de (mail.dynms.de [85.25.184.156]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973651ACF1C for ; Sat, 16 May 2015 00:43:27 -0700 (PDT) Received: from [10.10.10.101] (chello084112032036.1.11.vie.surfer.at [84.112.32.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dynms.de (Postfix) with ESMTPSA id 4CAC05461F16 for ; Sat, 16 May 2015 09:43:23 +0200 (CEST) From: Patrick Gansterer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> Date: Sat, 16 May 2015 09:43:23 +0200 To: oauth@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Wed, 20 May 2015 09:01:41 -0700 Subject: [OAUTH-WG] redircet_uri matching algorithm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 07:43:29 -0000 "OAuth 2.0 Dynamic Client Registration Protocol=E2=80=9D [1] is nearly = finished and provides the possibility to register additional =E2=80=9CClie= nt Metadata=E2=80=9D. OAuth 2.0 does not define any matching algorithm for the redirect_uris. = The latest information on that topic I could find is [1], which is 5 = years old. Is there any more recent discussion about it? I=E2=80=99d suggest to add an OPTIONAL = =E2=80=9Credirect_uris_matching_method=E2=80=9D client metadata. = Possible valid values could be: * =E2=80=9Cexact=E2=80=9D: The =E2=80=9Credirect_uri" provided in a = redirect-based flow must match exactly one of of the provided strings in = the =E2=80=9Credirect_uris=E2=80=9D array. * =E2=80=9Cprefix=E2=80=9D: The "redirect_uri" must begin with one of = the =E2=80=9Credirect_uris=E2=80=9D. (e.g. = "http://example.com/path/subpath=E2=80=9D would be valid with = [=E2=80=9Chttp://example.com/path/=E2=80=9C, = =E2=80=9Chttp://example.com/otherpath/=E2=80=9D]) * =E2=80=9Cregex=E2=80=9D: The provided =E2=80=9Credirect_uris=E2=80=9D = are threatened as regular expressions, which the =E2=80=9Credirect_uri=E2=80= =9D will be matched against. (e.g. = =E2=80=9Chttp://subdomain.example.com/path5/=E2=80=9C would be valid = with [=E2=80=9C^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/=E2=80=9C] If not defined the server can choose any supported method, so we do not = break existing implementations. On the other side it allows an client to = make sure that a server supports a specific matching algorithm required = by the client. ATM a client has no possibility to know how a server = handles the redirect_uris. [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html -- Patrick Gansterer