Right, Torsten has nailed this use case: it's not tied to unregistered clients, though they could be useful there, too. We've seen need for this in both an installed app (actually, a Java Web Start app) and a server-based email gateway system. In both cases, one user can register multiple instances of the client -- in the former, different browsers or machines with the same app, in the latter, different email addresses. In both cases, the client could potentially provide some instance-identifiable information while using the same client ID for all instances.
-- Justin On Tue, 2010-07-27 at 06:48 -0400, Torsten Lodderstedt wrote: > I think the proposed parameters are useful for registered clients, too. > For installed applications, there is always the chance a user authorizes > the same application (==binary==client_id?) several times, every time on > a different device. It would be helpful to differentiate those copies. > > regards, > Torsten. > > Am 17.07.2010 00:23, schrieb Marius Scurtescu: > > I agree that these parameters are useful, but not sure if they belong > > in the User Experience extension. > > > > I think we should create a separate extension for unregistered clients: > > - how to signal that this client is unregistered, maybe use a special > > value like "anonymous" as the client id > > - what client name/description should be used, as you suggest here > > > > Instead of instance_name and instance_description maybe we can call > > these client_name and client_description? > > > > Marius > > > > > > > > On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P.<jric...@mitre.org> > > wrote: > > > >> I'd like to propose the addition of two more optional parameters to this > >> extension: > >> > >> instance_name > >> Short, human-readable name that the server SHOULD display to > >> the end-user along with the client name. This name is designed > >> to reflect a per-instance identifier for cases where a single user > >> may authorize multiple copies of a single identified client. The > >> server MAY [SHOULD?] store this information along with its > >> associated access grant to allow the end-user to differentiate > >> between instances of the application in the future (for example, > >> to revoke access tokens). > >> > >> instance_description > >> A longer, human-readable description that the server MAY display to > >> the end-user along with the client name. This description is designed > >> as the name above to reflect a per-instance identifier for cases where > >> a single user may authorize multiple copies of a single identified > >> client. The > >> server MAY [SHOULD?] store this information along with its > >> associated access grant to allow the end-user to differentiate > >> between instances of the application in the future (for example, > >> to revoke access tokens). If a client presents the instance_description, > >> it MUST also present an instance_name. > >> > >> This can be thought of as the new way of Google's xoauth_display_name > >> parameter. We have a direct use case for this, and it seems like it would > >> fit in the UX more than its own extension. > >> > >> There was also talk of sending a client-information URL to get more stuff > >> about the client and instances of it, but that seems a better fit for the > >> impending discovery spec, to me, as it seems to address full client > >> information and not per-instance information that this is talking about. > >> > >> -- Justin > >> ________________________________________ > >> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of David > >> Recordon [record...@gmail.com] > >> Sent: Monday, July 12, 2010 3:51 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] Moving the User Experience Extension draft forward > >> > >> 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 > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
