On Mon, 2010-08-30 at 10:53 -0400, David Recordon wrote: > On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer <jric...@mitre.org> > wrote: > 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. > > > 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. > 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
