Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward

From: Marius Scurtescu <[email-masked]>
Date: Wed, 25 Aug 2010 13:39:57 -0700

David,

Here is some feedback I received internally from Greg Robbins:

"Having "display" as an extension is useful, though considering the
trend towards tablet devices like the iPad, "touch" and "popup" seem
orthogonal rather than mutually exclusive.

It would also be nice if the client could indicate the dimensions
available for display so the server can make a smarter presentation.
Desktop, netbook, tablet, and mobile screen dimensions vary widely
now."

Marius

On Mon, Jul 12, 2010 at 12:51 PM, David Recordon <[email-masked]> wrote:
> I wrote this draft last month based on discussions on the mailing list, the
> OpenID user experience extension (which Facebook, Google, and Yahoo! have
> deployed), and some OAuth 2.0 implementation experience from Facebook. It
> defines language and display preferences which the client can include in
> requests to the end-user authorization endpoint.
> A previous draft included an immediate mode parameter but further discussion
> has shown that it should be removed until identity information is also
> addressed. Identity is outside the scope of this particular extension.
> I'd like this draft to become a working group document and have done my best
> to make it represent the group's consensus. Unfortunately the internet draft
> submission process is closed for a few weeks until after the meeting. :-\
> Thanks,
> --David
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 25 Aug 2010 13:55:32 -0700

We are in support, and have implemented display

- cmort

---

From: David Recordon <[email-masked]>
Date: Fri, 27 Aug 2010 20:23:27 +0000

Given our implementation experience, an iPad should use "popup" as it's a
full web browser on a reasonably large screen. Android and the iPhone should
use "touch". I'd be happy to add clarifying language in the extension but am
weary about adding the complexity of the client requesting dimensions.

As a side note, this draft is now up at
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.

--David

---

From: David Recordon <[email-masked]>
Date: Fri, 27 Aug 2010 20:27:13 +0000

And to follow that up, I'd like to request that this draft moves to become a
Working Group item. I'm am happy to continue acting as the editor.

---

From: Justin Richer <[email-masked]>
Date: Fri, 27 Aug 2010 16:37:16 -0400

Does the group have an opinion on adding the instance information that I
proposed before* to this UX extension vs. having it live in its own
extension? 

 -- Justin

* http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html

On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
> Given our implementation experience, an iPad should use "popup" as
> it's a full web browser on a reasonably large screen. Android and the
> iPhone should use "touch". I'd be happy to add clarifying language in
> the extension but am weary about adding the complexity of the client
> requesting dimensions.
> 
> 
> As a side note, this draft is now up
> at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
> 
> 
> --David
> 
> 
> On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu
> <[email-masked]> wrote:
>         David,
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 27 Aug 2010 15:47:10 -0700

+1 on making this a WG item (as well as the device draft).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Friday, August 27, 2010 1:27 PM
To: OAuth WG
Cc: Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward

And to follow that up, I'd like to request that this draft moves to become a Working Group item. I'm am happy to continue acting as the editor.

On Fri, Aug 27, 2010 at 8:23 PM, David Recordon <[email-masked]<mailto:[email-masked]>> wrote:
Given our implementation experience, an iPad should use "popup" as it's a full web browser on a reasonably large screen. Android and the iPhone should use "touch". I'd be happy to add clarifying language in the extension but am weary about adding the complexity of the client requesting dimensions.

As a side note, this draft is now up at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.

--David

On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
David,

Marius

On Mon, Jul 12, 2010 at 12:51 PM, David Recordon <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

---

From: David Recordon <[email-masked]>
Date: Sat, 28 Aug 2010 02:06:07 +0000

Hey Justin, what's a good example of where the instance name parameter would
be used? Desktop apps like TweetDeck just ask me to authorize "TweetDesk"
and don't separate between my laptop and desktop. Another example would be
our Facebook mobile apps but "Facebook for iPhone" has a different client id
than "Facebook for Android".

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Aug 2010 20:08:03 +0200

David,

any opinion on screen orientation and size?

regards,
Torsten.

Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
> If I understand your proposal correctly, you assume the clients knows 
> better than the authz server how to fit the client presentation 
> capabilities the best.
>
> Wouldn't it be neccessary to also tell the authz server the screen 
> orientation and available size?
>
> regards,
> Torsten.
>
> Am 12.07.2010 21:51, schrieb David Recordon:
>> I wrote this draft last month based on discussions on the mailing 
>> list, the OpenID user experience extension (which Facebook, Google, 
>> and Yahoo! have deployed), and some OAuth 2.0 implementation 
>> experience from Facebook. It defines language and display preferences 
>> which the client can include in requests to the end-user 
>> authorization endpoint.
>>
>> A previous draft included an immediate mode parameter but further 
>> discussion has shown that it should be removed until identity 
>> information is also addressed. Identity is outside the scope of this 
>> particular extension.
>>
>> I'd like this draft to become a working group document and have done 
>> my best to make it represent the group's consensus. Unfortunately the 
>> internet draft submission process is closed for a few weeks until 
>> after the meeting. :-\
>>
>> Thanks,
>> --David
>>
>>

---

From: David Recordon <[email-masked]>
Date: Sat, 28 Aug 2010 11:20:46 -0700

I guess my reply is similar to Marius. We haven't had a need for it yet in
our production deployment.

On Sat, Aug 28, 2010 at 11:08 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> better than the authz server how to fit the client presentation capabilities
> the best.
>
> discussion has shown that it should be removed until identity information is
> also addressed. Identity is outside the scope of this particular extension.
>
>  I'd like this draft to become a working group document and have done my
> best to make it represent the group's consensus. Unfortunately the internet
> draft submission process is closed for a few weeks until after the meeting.
> :-\
>
>  Thanks,
> --David
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Aug 2010 20:45:36 +0200

So your login forms e.t.c. are the same for horicontal (e.g. iPad) and 
vertical (e.g. iPhone/normal operation) orientation?

what posting of Marius do you refer to?

regards,
Torsten.

Am 28.08.2010 20:20, schrieb David Recordon:
> I guess my reply is similar to Marius. We haven't had a need for it 
> yet in our production deployment.
>
>
> On Sat, Aug 28, 2010 at 11:08 AM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     David,
>
>>     If I understand your proposal correctly, you assume the clients
>>     knows better than the authz server how to fit the client
>>     presentation capabilities the best.
>>
>>     Wouldn't it be neccessary to also tell the authz server the
>>     screen orientation and available size?
>>
>>     regards,
>>     Torsten.
>>
>>>     I wrote this draft last month based on discussions on the
>>>     mailing list, the OpenID user experience extension (which
>>>     Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0
>>>     implementation experience from Facebook. It defines language and
>>>     display preferences which the client can include in requests to
>>>     the end-user authorization endpoint.
>>>
>>>     A previous draft included an immediate mode parameter but
>>>     further discussion has shown that it should be removed until
>>>     identity information is also addressed. Identity is outside the
>>>     scope of this particular extension.
>>>
>>>     I'd like this draft to become a working group document and have
>>>     done my best to make it represent the group's consensus.
>>>     Unfortunately the internet draft submission process is closed
>>>     for a few weeks until after the meeting. :-\
>>>
>>>     Thanks,
>>>     --David
>>>
>>>
>>>     [email-masked]  <mailto:[email-masked]>
>>     [email-masked]  <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Aug 2010 20:46:25 +0200

+1 on making this a WG item

Am 27.08.2010 22:23, schrieb David Recordon:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     David,
>
>     On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     mailing list, the
>     further discussion
>     done my best

---

From: Justin Richer <[email-masked]>
Date: Mon, 30 Aug 2010 10:02:07 -0400

Your first example is the textbook case, actually. You're still being
asked to authorize TweetDeck, which is identified by its client_id
parameter. Say your laptop gets stolen -- you'd want to be able to
differentiate between the two "TweetDeck" tokens listed on your
authorized apps account instead of nuking all tokens for that client.
You're right in that the Facebook example you gave below doesn't apply,
unless someone has multiple iPhones or Androids. 

XMPP already does this kind of thing, allowing you to set the "Resource"
field so you know at some level which endpoint you're actually talking
to, even though the account name is the same across all of them. 

The important thing is that this information would be a hint, meant to
be human-readable, and only trusted insofar as the client itself is
trusted to present information (since it's intended to be used in both
registered and unregistered/dynamic clients). The instance_name would
not be a replacement for a registered client name, but an optional
addendum to it. The server has the option of allowing the user to edit
it, though I believe Google has some data about that not actually
happening in practice. 

We've got two direct use cases for this. One system is a Java WebStart
client that is accessible from a browser but stores its creds on the
local machine. Different browsers and different machines can get
different instances of the same app, and our users end up with a whole
stack of authorizations for the same app with no way to tell them apart
from the server after the fact. The other case is a system that uses
email as the gateway, and each email address gets its own authorization
token. In this case, all the credentials are stored on a web/email
server but are tied to different entry points. However we end up with
the same problem as above, where all instances of the same client look
identical to the end user. 

All that this proposal really does is give us a standard slot to put
identification information for the different tokens. 

 -- justin

On Fri, 2010-08-27 at 22:06 -0400, David Recordon wrote:
> Hey Justin, what's a good example of where the instance name parameter
> would be used? Desktop apps like TweetDeck just ask me to authorize
> "TweetDesk" and don't separate between my laptop and desktop. Another
> example would be our Facebook mobile apps but "Facebook for iPhone"
> has a different client id than "Facebook for Android".
> 
> 
>         *
>         http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
>         
>         
>         >         trend towards tablet devices like the iPad, "touch"
>         and
>         >         "popup" seem
>         >         It would also be nice if the client could indicate
>         the
>         >         dimensions
>         >         available for display so the server can make a
>         smarter
>         >         presentation.
>         >         Desktop, netbook, tablet, and mobile screen
>         dimensions vary
>         >         widely
>         >         now."
>         >
>         >         Marius
>         >
>         >
>         >
>         >
>         >         <[email-masked]> wrote:
>         >         > OpenID user experience extension (which Facebook,
>         Google,
>         >         and Yahoo! have
>         >         > deployed), and some OAuth 2.0 implementation
>         experience from
>         >         Facebook. It
>         >         > defines language and display preferences which the
>         client
>         >         can include in
>         >         > addressed. Identity is outside the scope of this
>         particular
>         >         extension.
>         >         > I'd like this draft to become a working group
>         document and
>         >         have done my best
>         >         > to make it represent the group's consensus.
>         Unfortunately
>         >         the internet draft
>         >         > submission process is closed for a few weeks until
>         after the
>         >         meeting. :-\
>         >         > Thanks,
>         >         > --David
>         >
>         >

---

From: David Recordon <[email-masked]>
Date: Mon, 30 Aug 2010 07:53:56 -0700

> authorized apps account instead of nuking all tokens for that client.

That makes sense, but none of the servers TweetDeck works with support this
concept today. I like it, but only want to standardize what we've seen to
work in the wild. (This is why I argued that the device flow shouldn't be in
core because the community hasn't successfully deployed it yet.)

---

From: Justin Richer <[email-masked]>
Date: Mon, 30 Aug 2010 11:02:10 -0400

On Mon, 2010-08-30 at 10:53 -0400, David Recordon wrote:
> That makes sense, but none of the servers TweetDeck works with support
> this concept today. I like it, but only want to standardize what we've
> seen to work in the wild. (This is why I argued that the device flow
> shouldn't be in core because the community hasn't successfully
> deployed it yet.)

And likewise, I'm totally fine with it being in an extension. The
question was whether to put it in the UX extension or a separate
Instance-Data extension instead.

>         > On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer
>         <[email-masked]>
>         > wrote:
>         >         Does the group have an opinion on adding the
>         instance
>         >         information that I
>         >         proposed before* to this UX extension vs. having it
>         live in
>         >         its own
>         >         extension?
>         >
>         >          -- Justin
>         >
>         >         *
>         >
>         >         > Given our implementation experience, an iPad
>         should use
>         >         "popup" as
>         >         > it's a full web browser on a reasonably large
>         screen.
>         >         Android and the
>         >         > iPhone should use "touch". I'd be happy to add
>         clarifying
>         >         language in
>         >         > the extension but am weary about adding the
>         complexity of
>         >         the client
>         >         > requesting dimensions.
>         >         >
>         >         >
>         >         > at
>         >         >         Here is some feedback I received
>         internally from
>         >         Greg Robbins:
>         >         >
>         >         >         "Having "display" as an extension is
>         useful, though
>         >         >         considering the
>         >         >         > I wrote this draft last month based on
>         discussions
>         >         on the
>         >         >         mailing list, the
>         >         >         > A previous draft included an immediate
>         mode
>         >         parameter but
>         >         >         further discussion
>         >         >         > has shown that it should be removed
>         until identity
>         >         >         information is also