i like having an optional hint / parameter which would hint to the server which type of response the client wants back. whether or not this needs to be "core" or an "extension", however, is a valid question.
twitter is actually facing the same issue that david mentions, and have implemented something similar to what is detailed here. On Tue, Mar 30, 2010 at 3:16 PM, David Recordon <[email protected]> wrote: > On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes <[email protected]> wrote: > > This seems rather application-specific. What semantics do these things > take > > on when HTTP is just being used as a transport, e.g., for a virtual world > > system (see VWRAP)? > > > > Also, maybe I'm misunderstanding things here, but since it's the Client > that > > send the browser to the authorization page, doesn't the Client control > how > > the authorization page is displayed? In an iframe, popup, etc... > > Yes, but the Client needs to make sure that the authorization page > will fit in whatever constraints they're choosing. This might be a > popup window but could also be a full page redirect. There's also the > case in the Web Client flow where the Client just wants an immediate > response of yes/no (ala OpenID's checkid_immediate mode) versus > presenting any UI in the first request. > > > > Perhaps what you want here is a set of different authorization URIs that > > result in different appearances (e.g., desktop vs. mobile)? You're > already > > assuming that the application developer knows which of these options he > > wants. > > There are a few ways to go about it: > 1) different mainly duplicative versions of the Web Client and Web Server > flows > 2) multiple modes within the existing Web Client and Web Server flows > 3) different user authorization endpoints which can be used with > either the Web Client or Web Server flow > 4) an optional parameter like in this proposal > > I'd rather have this be something more dynamic than multiple hard > coded user authorization URLs and duplicating flows seems more > confusing to developers. > > --David > > > --Richard > > > > > > > > On Mar 30, 2010, at 4:54 PM, David Recordon wrote: > > > >> One of the challenges we're running into from an implementation > standpoint > >> is having the ability for a Client developer to tell the Authorization > >> Server if they're looking for a popup, full page redirect, mobile > >> experience, or no user interface for the times when a user is being sent > >> through an authorization flow. We're thinking that an additional > "display" > >> parameter would be useful within the Web Client and Web Server flows. > >> Values would include none, page, popup, and mobile. > >> > >> none - Mainly for the Web Client profile. The Authorization Server > should > >> return an immediate response either as an error or an access token if > the > >> user has already authorized the Client and has a current session. > >> > >> popup - The Client is intending to display the Authorization Server's > user > >> authorization flow within a popup window. Negotiating size seems > reasonable > >> to exclude from scope for now. > >> > >> page - The Client is redirecting the user's browser to a page on the > >> Authorization Server. (This is probably the default and could be > unneeded.) > >> > >> mobile - Force a mobile experience instead of the normal full page. > >> > >> Most Clients will never need to use this parameter because it will > >> automatically work using the standard OAuth redirect, but developers can > >> override it and it's needed in the Web Client flow. > >> > >> --David > >> _______________________________________________ > >> 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 > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
