Re: [OAUTH-WG] redirect uri validation

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 15 August 2011 06:57 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2707611E8081 for <oauth@ietfa.amsl.com>; Sun, 14 Aug 2011 23:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Level:
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_102=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72vx8IaCUeYy for <oauth@ietfa.amsl.com>; Sun, 14 Aug 2011 23:57:36 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AB14F11E8082 for <oauth@ietf.org>; Sun, 14 Aug 2011 23:57:36 -0700 (PDT)
Received: (qmail 15140 invoked from network); 15 Aug 2011 06:58:21 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:58:21 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:58:21 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "eran@sled.com" <eran@sled.com>, Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Sun, 14 Aug 2011 23:57:10 -0700
Thread-Topic: [OAUTH-WG] redirect uri validation
Thread-Index: AcxK8ixmC0aAySH5S26xwHZeEopeLwQH5tlwAAGqMzA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <fcffd9492cbaced09c93f4e3c37b569f@lodderstedt-online.de> <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "torsten@lodderstedt-online.de" <torsten@lodderstedt-online.de>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] redirect uri validation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Aug 2011 06:57:37 -0000

Added to 1.4.2:

            When issuing an implicit grant, the authorization server does not authenticate the
            client and [[in some cases]], the client identity [[can]] be verified via the redirection URI
            used to deliver the access token to the client. The access token may be exposed to the
            resource owner or other applications with access to the resource owner's user-agent.

Hope this is sufficient.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, August 14, 2011 11:09 PM
> To: Torsten Lodderstedt
> Cc: torsten@lodderstedt-online.de; oauth@ietf.org
> Subject: Re: [OAUTH-WG] redirect uri validation
> 
> Where would you suggest I add this?
> 
> EHL
> 
> > -----Original Message-----
> > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> > Sent: Monday, July 25, 2011 10:42 AM
> > To: Eran Hammer-Lahav
> > Cc: torsten@lodderstedt-online.de; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] redirect uri validation
> >
> > Hi Eran,
> >
> > >>> OAuth 1.0 was highly criticized for failing to address client
> > >>> identity in public clients. I believe OAuth 2.0 offers a much
> > >>> better story, within the boundaries>of what’s possible today.
> > >> Agreed. I think we must honestly discuss the value of client
> > >> authentication/identification itself. I personally think it is
> > >> over-emphazised right now. The strength of OAuth 2.0 is that it
> > >> allows solutions where neither client nor resource server have
> > >> access or
> > do store end-user credentials.
> > >> Client authentication is nice but not the main feature.
> > > Do you have any specific suggestions not already mentioned on the list?
> >
> > I would suggest to mention that while an invalid redirect_uri
> > indicates a counterfeit clients a valid redirect does not prove the calling
> client's identity.
> >
> > regards,
> > Torsten.
> >
> >
> > > EHL
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth