Yes, shorter is better, and we'll get to it later. But all the flows use a single endpoint (right now), so each request needs a unique type.
EHL On 4/1/10 7:02 PM, "Paul Walker" <catch-...@paulwalker.tv> wrote: > Along those lines, I would suggest renaming the mode values as the terms > "request" and "flow" are kinda superfluous. Perhaps > > mode=web_callback > mode=web_client > mode=device > mode=credentials > mode=client > > I understand that the Web Callback Flow uses two different values, one for the > authorization step and another for the access token, but is this really needed > given that these are different uris? > > > On Mar 31, 2010, at 10:28 PM, Luke Shepard wrote: > >> At first, I had the same first reaction as Marius, but after reading this >> thread, I agree with Eran. Two observations: >> >> 1/ OAuth endpoints are usually already namespaced as "oauth" - if there are >> other endpoints that accept custom parameters, they can be defined elsewhere. >> For example: >> >> https://www.google.com/accounts/OAuthAuthorizeToken >> https://api.login.yahoo.com/oauth/v2/request_auth >> http://twitter.com/oauth/authorize >> >> 2/ We should fight to keep URLs short and leave out redundant information >> where possible. We should leave out redundant information where possible. >> >> Here are two sample URLs. The first is 12% shorter than the second. >> >> http://facebook.com/oauth/authorize?mode=web_callback_access_request&client_i >> d=123456789&callback=http://facebook.com/oauth/callback >> http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oa >> uth_client_id=123456789&oauth_callback=http://facebook.com/oauth/callback >> >> >> >> On Mar 31, 2010, at 9:17 PM, Eran Hammer-Lahav wrote: >> >>> Hey Marius, >>> >>> On 3/31/10 8:37 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: >>> >>>> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <e...@hueniverse.com> >>>> wrote: >>>>> The only significant change I have made (which is of course open to >>>>> debate) >>>>> is renaming all the authorization flows parameters. I dropped the oauth_ >>>>> prefix (no real need since these are purely OAuth endpoints, not protected >>>>> resources), and made most of the parameter names shorter. I am not done so >>>>> they are not consistent yet. >>>> >>>> Having a common prefix for all parameters is quite important IMO. It >>>> allows parties >>>> to define and pass additional, non-standard, parameters. >>> >>> Non-standard parameter hurt interoperability. The question is whether the >>> right approach is to add a prefix to the protocol parameters or to the >>> extension parameters (such as x_), or none. >>> >>> What prevents a custom parameter to collide with a standard extension not >>> supported by the server or someone else's custom parameter? If we are >>> serious about parameter collision (which I doubt given past sentiments on >>> registries etc.), we should require all parameters to register unless they >>> have some special custom prefix. >>> >>> In other word, adding the oauth_ prefix to the core parameters doesn't >>> really accomplish much, other than making requests longer. In the past, >>> people wanted to define extension parameters starting with oauth_ and we >>> didn't really reach consensus on whether to allow it or not. Then we played >>> with xoauth_ for a while, then went back and just allowed oauth_ for >>> extensions. >>> >>> If we keep the oauth_ prefix, do we also require a registry for extensions? >>> Do we define another prefix? Do we create a registry for extension prefixes? >>> This gets bad really fast. >>> >>>> Also, quite >>>> often parameters >>>> are added to existing URLs, and a prefix helps prevent collisions. >>> >>> Extension parameters should never conflict with core parameter because we >>> know all the core parameters before we write custom ones... >>> >>> This is only for the OAuth-specific endpoint (authorization endpoint), not >>> the protected resource endpoint in which we will still use oauth_token (the >>> only parameter added to protected resource requests). >>> >>> What do you think? >>> >>> 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
