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 > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
