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