Seems like we could also simply put up a 1.0a PR that issues a 2.0 token. That avoids wedging 1.0 stuff into 2.0.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Torsten Lodderstedt > Sent: Saturday, July 17, 2010 5:31 AM > To: Justin Richer > Cc: [email protected] > Subject: Re: [OAUTH-WG] Alternative Upgrade Flow > > I think we gonna need additional end points anyway, e.g. for > token revocation. So why not use another endpoint for that > purpose? That way the tokens endpoint is not overloaded to much. > > regards, > Torsten. > > Am 16.07.2010 18:48, schrieb Justin Richer: > > The current proposal for a 1.0->2.0 upgrade flow is to use the > > assertion profile and pass the OAuth token in there. Instead, one > > could create an endpoint that speaks the 1.0 protocol fully, > > signatures and client secrets and everything, but issues > 2.0 tokens, > > JSON and all. It's a hybridized endpoint also, but put > together with > > the opposite pieces. In both cases, you put a 1.0 token in > one end and > > get a 2.0 token out the other. But in this case, the request being > > made is a completely vanilla OAuth 1.0 protected resource > access request. > > > > Does this really need a separate endpoint, or can we extend the > > grant_type options to include "oath1.0" in an extension? I > know that > > extensions aren't currently allowed to make new grant_types > -- I think > > they should be able to and and proposing that we allow that > extension > > point. I dislike the reasoning of "just cram it all into an > assertion > > to extend", since it doesn't allow for clients to separate > out their > > parameters easily. > > > > -- Justin > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
