Because the server can deploy support for new devices after the client is released and deployed. Wouldn't it be better if the client didn't need a new release to take advantage of something as trivial as asking the server for a better interface?
EHL On 3/30/10 5:25 PM, "Raffi Krikorian" <[email protected]> wrote: why does a client need to discover what the server supports? presumably the client would already know given that they are integrating with it? it could simply be documented somewhere (just looking for a way for this not to snowball into something complicated). On Tue, Mar 30, 2010 at 5:22 PM, Eran Hammer-Lahav <[email protected]> wrote: This should be implemented using a parameter with some level of discovery to find out the options supported by the server. As for where this belongs (extension, etc), I say write it and we'll figure it out later. It will be part of core more based on the libraries and companies that adopt it than what the core spec says. EHL On Mar 30, 2010, at 18:16, "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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
