Sounds like something best outlined in a best-practices doc or extension - there are going to be a lot of different implementation specific things here I think.
We're not doing it right now, but Photobucket will be doing some light user agent detection, with a hint option, for this sort of interaction. On Tue, Mar 30, 2010 at 4:22 PM, Raffi Krikorian <ra...@twitter.com> wrote: > 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 <record...@gmail.com>wrote: > >> On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes <rbar...@bbn.com> 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 >> >> 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 >> > > > > -- > Raffi Krikorian > Twitter Platform Team > http://twitter.com/raffi > > _______________________________________________ > 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
