I guess I'm one of those IETF folks that likes to separate content
from presentation :)
In any case, it seems like there's some agreement here that display
parameters are something that should be optional / extension. That's
fine with me.
It sounds, though, like maybe what you want is a way to describe
criteria? (Rather than a set of tokens) E.g., if you just passed in
the x/y dimensions of the space that the authorization server would
have available to it, then the server could customize the UI to that
space. Would that be enough for the use cases you have in mind?
--Richard
On Mar 30, 2010, at 6:16 PM, David Recordon 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
