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

From: Luke Shepard <[email-masked]>
Date: Fri, 9 Apr 2010 03:24:56 -0700

I am still not sure why we *need* discovery in order to just add a "display" parameter to the spec.

I would like to see a set like the following supported:

-          popup

-          fullpage

-          touch (for smart phones (like iPhone)-like phones)

-          mobile (for older-mobile phones)

-          none

As Allen mentioned, the "popup" mode was already defined with some success in OpenID UX: http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor4

I agree that it can be difficult to standardize all of these right now - I think the best is to see what's being used in production now by different players and  see if we can get agreement on that. At least some broad categories could be established now to aid interop.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, March 30, 2010 6:34 PM
To: Marius Scurtescu; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

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

On Tue, Mar 30, 2010 at 8:50 PM, Anthony Nadalin <[email-masked]> wrote:
> 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.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 06:04:40 -0700

Can you submit a proposal?

On Apr 9, 2010, at 13:25, "Luke Shepard" <[email-masked]<mailto:[email-masked]>> wrote:

I am still not sure why we *need* discovery in order to just add a “display” parameter to the spec.

-          popup

-          fullpage

-          none

As Allen mentioned, the “popup” mode was already defined with some success in OpenID UX: <http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor4> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor4

I agree that it can be difficult to standardize all of these right now – I think the best is to see what’s being used in production now by different players and  see if we can get agreement on that. At least some broad categories could be established now to aid interop.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, March 30, 2010 6:34 PM
To: Marius Scurtescu; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

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.

EHL

On 3/30/10 5:58 PM, "Marius Scurtescu" <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Aren't these independent issues?

Marius

On Tue, Mar 30, 2010 at 8:50 PM, Anthony Nadalin <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
> From: <[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of Brian Eaton
> On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/oauth> https://www.ietf.org/mailman/listinfo/oauth
>
> <[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/oauth> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
<[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

---

From: Allen Tom <[email-masked]>
Date: Fri, 09 Apr 2010 17:20:40 -0700

+1

Not sure If it¹s possible for different SPs to agree on the specs for each
mode, but as we learned from implementing OpenID, it¹s very useful for the
client to have an interface to indicate to the AS how the UI should be
rendered. 

At least in Yahoo¹s case, we¹d like to see all the display modes you listed,
although I¹m unclear what ³none² is.

Allen

On 4/9/10 3:24 AM, "Luke Shepard" <[email-masked]> wrote:

> I am still not sure why we *need* discovery in order to just add a ³display²
> parameter to the spec.
>  
> As Allen mentioned, the ³popup² mode was already defined with some success in
> OpenID UX: 
> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-use
> r-interface-extension-1_0.html#anchor4
>  
> I agree that it can be difficult to standardize all of these right now  I
> think the best is to see what¹s being used in production now by different
> players and  see if we can get agreement on that. At least some broad
> categories could be established now to aid interop.
>  
> 
> 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
> 
> 
>> > 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
>> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Apr 2010 09:08:29 +0200

+1

Am 10.04.2010 02:20, schrieb Allen Tom:
> +1
>
> Not sure If it's possible for different SPs to agree on the specs for 
> each mode, but as we learned from implementing OpenID, it's very 
> useful for the client to have an interface to indicate to the AS how 
> the UI should be rendered.
>
> At least in Yahoo's case, we'd like to see all the display modes you 
> listed, although I'm unclear what "none" is.
>
> Allen
>
>
>
>
>     I am still not sure why we **need** discovery in order to just add
>     a "display" parameter to the spec.
>
>     As Allen mentioned, the "popup" mode was already defined with some
>     success in OpenID UX:
>     http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor4
>
>     I agree that it can be difficult to standardize all of these right
>     now -- I think the best is to see what's being used in production
>     now by different players and  see if we can get agreement on that.
>     At least some broad categories could be established now to aid
>     interop.
>
>
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Eran Hammer-Lahav
>     *Sent:* Tuesday, March 30, 2010 6:34 PM
>     *To:* Marius Scurtescu; Anthony Nadalin
>     *Cc:* OAuth WG
>     *Subject:* Re: [OAUTH-WG] A display parameter for user
>     authorization requests
>
>     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
>
>
>     > 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
>     >
>     ------------------------------------------------------------------------

---

From: Naitik Shah <[email-masked]>
Date: Sat, 10 Apr 2010 12:54:40 -0700

"none" is similar to check immediate in open id.

On Fri, Apr 9, 2010 at 5:20 PM, Allen Tom <[email-masked]> wrote:

>  +1
>
> Not sure If it’s possible for different SPs to agree on the specs for each
> mode, but as we learned from implementing OpenID, it’s very useful for the
> At least in Yahoo’s case, we’d like to see all the display modes you
> listed, although I’m unclear what “none” is.
>
> Allen
>
>
>
>
>
> I am still not sure why we **need** discovery in order to just add a
> “display” parameter to the spec.
>
> As Allen mentioned, the “popup” mode was already defined with some success
> in OpenID UX:
> I agree that it can be difficult to standardize all of these right now – I
> think the best is to see what’s being used in production now by different
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Eran Hammer-Lahav
> *Subject:* Re: [OAUTH-WG] A display parameter for user authorization
> requests
>
> 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
> 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
> discovery, this feature offers little interop value (which means little
> reason to write as a standard).
>
> EHL
>
>
> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Brian Eaton
> ------------------------------

---

From: Chuck Mortimore <[email-masked]>
Date: Sat, 10 Apr 2010 13:07:13 -0700

+1 - we'll end up requiring some parameter, as agent sniffing can't handle all our needs.

- cmort

On 4/10/10 12:08 AM, "Torsten Lodderstedt" <[email-masked]> wrote:

+1

Am 10.04.2010 02:20, schrieb Allen Tom:
Re: [OAUTH-WG] A display parameter for user authorization requests +1

Not sure If it's possible for different SPs to agree on the specs for each mode, but as we learned from implementing OpenID, it's very useful for the client to have an interface to indicate to the AS how the UI should be rendered.

At least in Yahoo's case, we'd like to see all the display modes you listed, although I'm unclear what "none" is.

Allen

-         popup

-         fullpage

-         none

EHL

Marius

________________________________
_______________________________________________
OAuth mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/oauth

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 12 Apr 2010 09:51:22 -0700

+1 in general

Question about display=none - I missed this part before, and proposed a
different parameter (immediate=true) for the same purpose -
http://www.ietf.org/mail-archive/web/oauth/current/msg01694.html.

Anyone have thoughts on whether we should have a separate parameter for
immediate mode?

I could go either way, but have a slight preference for two parameters.
"immediate" feels like a significant functional difference while the display
variations are more of a UI hint.

Evan

On Sat, Apr 10, 2010 at 1:07 PM, Chuck Mortimore
<[email-masked]>wrote:

>  +1 – we’ll end up requiring some parameter, as agent sniffing can’t
> handle all our needs.
>
> - cmort
>
>
>
>  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.
>

---

From: Luke Shepard <[email-masked]>
Date: Mon, 12 Apr 2010 11:04:16 -0700

Yes- I threw that in there as one way of handling an immediate response. We will need the ability to do a background ping in an iframe, similar to checkid_immediate in OpenID.

I agree that the parameters are functionally different ... on the other hand, they are mutually exclusive (you won't ever have a display and an immediate parameter set to the same) so by making it one parameter, you avoid certain error cases (i.e., what does a server do with "display=page&immediate=true")

From: [email-masked] [mailto:[email-masked]] On Behalf Of Evan Gilbert
Sent: Monday, April 12, 2010 9:51 AM
To: Chuck Mortimore
Cc: OAuth WG
Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

+1 in general

Question about display=none - I missed this part before, and proposed a different parameter (immediate=true) for the same purpose - http://www.ietf.org/mail-archive/web/oauth/current/msg01694.html.

Anyone have thoughts on whether we should have a separate parameter for immediate mode?

I could go either way, but have a slight preference for two parameters. "immediate" feels like a significant functional difference while the display variations are more of a UI hint.

Evan

On Sat, Apr 10, 2010 at 1:07 PM, Chuck Mortimore <[email-masked]<mailto:[email-masked]>> wrote:
+1 - we'll end up requiring some parameter, as agent sniffing can't handle all our needs.

- cmort

On 4/10/10 12:08 AM, "Torsten Lodderstedt" <[email-masked]<http://[email-masked]>> wrote:
+1

Allen

On 4/9/10 3:24 AM, "Luke Shepard" <[email-masked]<http://[email-masked]>> wrote:

-         popup

-         fullpage

-         none

From: [email-masked]<http://[email-masked]> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
 Sent: Tuesday, March 30, 2010 6:34 PM
 To: Marius Scurtescu; Anthony Nadalin
 Cc: OAuth WG
 Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

EHL

On 3/30/10 5:58 PM, "Marius Scurtescu" <[email-masked]<http://[email-masked]>> wrote:
Aren't these independent issues?

Marius

On Tue, Mar 30, 2010 at 8:50 PM, Anthony Nadalin <[email-masked]<http://[email-masked]>> wrote:
> From: [email-masked]<http://[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Eaton
> On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian <[email-masked]<http://[email-masked]>> wrote:
> [email-masked]<http://[email-masked]>
> [email-masked]<http://[email-masked]>
_______________________________________________
OAuth mailing list
 [email-masked]<http://[email-masked]>
 https://www.ietf.org/mailman/listinfo/oauth

________________________________
_______________________________________________
OAuth mailing list
 [email-masked]<http://[email-masked]>
 https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<http://[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Apr 2010 13:32:25 -0700

Between language preferences, display configuration, and immediate check, I think it might be worth to move that work to another draft. Timeline-wise, this has the potential of slowing us down. I also fear getting what is now a pretty simple spec much more complicated.

Anyone cares to try a first draft or outline? I can do the editorial work if needed, but someone needs to write something first.

EHL

On 4/12/10 11:04 AM, "Luke Shepard" <[email-masked]> wrote:

+1 in general

Evan

On Sat, Apr 10, 2010 at 1:07 PM, Chuck Mortimore <[email-masked]> wrote:

- cmort

On 4/10/10 12:08 AM, "Torsten Lodderstedt" <[email-masked] <http://[email-masked]> > wrote:

+1

Allen

On 4/9/10 3:24 AM, "Luke Shepard" <[email-masked] <http://[email-masked]> > wrote:

-         popup

-         fullpage

-         none

From: [email-masked] <http://[email-masked]> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
 Sent: Tuesday, March 30, 2010 6:34 PM
 To: Marius Scurtescu; Anthony Nadalin
 Cc: OAuth WG
 Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

EHL

On 3/30/10 5:58 PM, "Marius Scurtescu" <[email-masked] <http://[email-masked]> > wrote:
Aren't these independent issues?

Marius

On Tue, Mar 30, 2010 at 8:50 PM, Anthony Nadalin <[email-masked] <http://[email-masked]> > wrote:
> From: [email-masked] <http://[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Eaton
> On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian <[email-masked] <http://[email-masked]> > wrote:
> [email-masked] <http://[email-masked]>
> [email-masked] <http://[email-masked]>
_______________________________________________
OAuth mailing list
 [email-masked] <http://[email-masked]>
 https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
 [email-masked] <http://[email-masked]>
 https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked] <http://[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Allen Tom <[email-masked]>
Date: Tue, 13 Apr 2010 12:36:54 -0700

At least with regards to the language preference, how about if we just copy
the openid.ui.lang parameter from the OpenID UI Extension?

http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-u
ser-interface-extension-1_0.html#anchor3

In flows in which the client redirects the user¹s web browser to authorize
access, the client MAY send the Authorization Server a hint regarding the
user¹s preferred language by sending the following parameter:

    lang
        The user¹s preferred languages as a [BCP 47] language priority list,
represented as a comma-separated list of BCP 47 basic language ranges in
decending priority order. For instance, the value ³fr-CA,fr-FR,en-CA²
represents the preference for French spoken in Canada, French spoken in
France, followed by English spoken in Canada.

The language preference hint SHOULD take precedence over the Accept-Language
HTTP header sent by the user¹s browser, and SHOULD take precedence over the
language preference inferred by the user¹s IP Address.

BCP 47:  http://tools.ietf.org/html/bcp47

Allen

On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

> Between language preferences, display configuration, and immediate check, I
> think it might be worth to move that work to another draft. Timeline-wise,
> this has the potential of slowing us down. I also fear getting what is now a
> pretty simple spec much more complicated.
> 
> Anyone cares to try a first draft or outline? I can do the editorial work if
> needed, but someone needs to write something first.
> 
> EHL
> 
>