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". > > > On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer <jric...@mitre.org> > 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 > > * > 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 > > <mscurte...@google.com> wrote: > > 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 > > <record...@gmail.com> 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 > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
