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...
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.
--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
