Subject: [OAUTH-WG] A display parameter for user authorization requests

From: David Recordon <[email-masked]>
Date: Tue, 30 Mar 2010 13:54:52 -0700

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

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 30 Mar 2010 17:34:24 -0400

I think it makes sense, but can this be an extension as opposed to be
added to core?

A related parameter IMO (could be part of the same extension) would be
l10n, in what language should the Authorization Server interact with
the user. OpenID I think has a similar extension.

Marius

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 Mar 2010 18:07:08 -0400

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.)
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: David Recordon <[email-masked]>
Date: Tue, 30 Mar 2010 15:16:34 -0700

On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes <[email-masked]> 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

>> 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.
>>
>> Authorization Server.  (This is probably the default and could be unneeded.)
>>
>> automatically work using the standard OAuth redirect, but developers can
>> override it and it's needed in the Web Client flow.
>>
>> --David

---

From: Raffi Krikorian <[email-masked]>
Date: Tue, 30 Mar 2010 15:22:51 -0700

i like having an optional hint / parameter which would hint to the server
which type of response the client wants back.  whether or not this needs to
be "core" or an "extension", however, is a valid question.

twitter is actually facing the same issue that david mentions, and have
implemented something similar to what is detailed here.

On Tue, Mar 30, 2010 at 3:16 PM, David Recordon <[email-masked]> wrote:

> standpoint
> should

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Justin Hart <[email-masked]>
Date: Tue, 30 Mar 2010 16:40:49 -0600

Sounds like something best outlined in a best-practices doc or extension -
there are going to be a lot of different implementation specific things here
I think.

We're not doing it right now, but Photobucket will be doing some light user
agent detection, with a hint option, for this sort of interaction.

On Tue, Mar 30, 2010 at 4:22 PM, Raffi Krikorian <[email-masked]> wrote:

> On Tue, Mar 30, 2010 at 3:16 PM, David Recordon <[email-masked]>wrote:
>
>> can

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Mar 2010 16:43:18 -0600

> coded user authorization URLs and duplicating flows seems more

I agree that defining multiple but essentially similar flows is a bad
idea. This seems like a good opportunity for defining an extension,
mostly because many IETF folks would probably prefer a separation
between meaning and presentation. But personally I'm willing to be
convinced otherwise. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 Mar 2010 18:50:49 -0400

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:

>> things take
>> Client that
>> that
>>> Server's user

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 30 Mar 2010 17:22:01 -0700

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

---

From: Raffi Krikorian <[email-masked]>
Date: Tue, 30 Mar 2010 17:25:44 -0700

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

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Brian Eaton <[email-masked]>
Date: Tue, 30 Mar 2010 17:44:10 -0700

On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian <[email-masked]> wrote:
> client would already know given that they are integrating with it?

+1.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 31 Mar 2010 00:50:47 +0000

So I doubt that the client always knows what the server supports, the server should be open in allowing all parties to find out what is supported

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Tuesday, March 30, 2010 5:44 PM
To: Raffi Krikorian
Cc: OAuth WG
Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian <[email-masked]> 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?

+1.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 30 Mar 2010 20:58:33 -0400

Aren't these independent issues?

Regardless how the client figures what the server supports (discovery
or hard code configuration) it must have a way to tell the
Authorization Server its preferences when it sends the user over.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 30 Mar 2010 18:27:09 -0700

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-masked]> 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-masked]> wrote:
This should be implemented using a parameter with some level of
discovery  to find out the options supported by the server.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 30 Mar 2010 18:33:46 -0700

They are, but thinking about interop for both parts is the same work. Once you figure out what the client might need, you figure out what the server may support. At that point discovery is as simple as giving these different options names and putting this information somewhere.

I am not saying a spec must cover both, but it is worth thinking about it at the same time. For example, a decision about allowing requesting custom size popup vs. fixed popup options vs. pre-defined categories, all require different discovery needs. If the feature allows the client to say "I want a 400x500 popup", you just need to say "popups are supported". But if you want just allow full browser or popup (of fixed sizes), and do not require a server to support all of them, you need to express what is supported.

Given the wide range of UI options, without either mandating everything or discovery, this feature offers little interop value (which means little reason to write as a standard).

EHL

On 3/30/10 5:58 PM, "Marius Scurtescu" <[email-masked]> wrote:

Marius