General discussions on the list and during the interim meeting. EHL
> -----Original Message----- > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Monday, August 02, 2010 1:20 PM > To: Eran Hammer-Lahav > Cc: OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] Extensibility: new endpoints > > What consensus do you refer to? The WG charter? > > regards, > Torsten. > > Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > > No according to WG consensus. We took it all out because too many people > considered it experimental, so while it may be a WG item, it is not part of > the > core spes. > > > > EHL > > > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:[email protected]] > >> Sent: Monday, August 02, 2010 1:07 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG ([email protected]) > >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >> > >> and discovery does not belong into the core? > >> > >> regards, > >> Torsten. > >> > >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > >> > >>> This doesn't belong in core. A registry is used to avoid name > >>> collisions, not > >>> > >> to provide an inventory. > >> > >>> Maybe in discovery. > >>> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:[email protected]] On > >>>> Behalf Of Torsten Lodderstedt > >>>> Sent: Monday, August 02, 2010 12:54 PM > >>>> To: OAuth WG ([email protected]) > >>>> Subject: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> the existing authorization server endpoints (end-user authorization > >>>> and tokens endpoint) have a relatively clearly semantics and scope. > >>>> Adding distinct new functions to an authorization server will (in > >>>> my > >>>> opionion) require the definition of new endpoints. For example, I'm > >>>> working on an I-D for token revocation. Such a function does not > >>>> fit into the tokens endpoint since it has become a "token issuance > >>>> endpoint" rather than a general purpose client2server endpoint. > >>>> > >>>> I therefore would propose to include the option to define and > >>>> register new endpoints into the Extensibility section of the spec. > >>>> This would also facilitate the incorporation of additional > >>>> endpoints (with well-defined names) into OAuth discovery. > >>>> > >>>> Any thoughts? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
