From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 25 Jun 2010 11:18:12 -0700
Thread-Topic: [OAUTH-WG] Extensibility for OAuth?
Thread-Index: AcsUkgtMuUUiIQrkTlOdovjsi2b5cwAAFinw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84999@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net>
 <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.com>
In-Reply-To: <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>,
 WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Extensibility for OAuth?
Precedence: list

I think the two endpoints are currently well defined. For example, the toke=
n endpoint always takes an access grant and turns it into an access token w=
ith optional refresh token. To "extend" it to say, register new clients dyn=
amically, is a bad thing. But adding a new parameter (such as language) is =
a good thing to support, and by requiring review, only parameters that don'=
t change the overall design will be approved.

EHL

> -----Original Message-----
> From: Dick Hardt [mailto:dick.hardt@gmail.com]
> Sent: Friday, June 25, 2010 11:13 AM
> To: Eran Hammer-Lahav
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
> Subject: Re: [OAUTH-WG] Extensibility for OAuth?
>=20
> Would you elaborate on your reasons here? Do you think we have
> enumerated all the possibilities?
>=20
> On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote:
>=20
> > I would rather limit the ability to extend the two endpoints beyond the=
ir
> current architecture, and instead, allow others to specify new endpoints =
(e.g.
> a device endpoint for getting an authorization code without using browser
> redirection) that work in addition to the token endpoint (using an existi=
ng
> grant type or assertion).