I think the two endpoints are currently well defined. For example, the token endpoint always takes an access grant and turns it into an access token with optional refresh token. To "extend" it to say, register new clients dynamically, 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.ha...@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? > > Would you elaborate on your reasons here? Do you think we have > enumerated all the possibilities? > > On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: > > > I would rather limit the ability to extend the two endpoints beyond their > 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 existing > grant type or assertion). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
