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
