Good question. Probably because the authz servers wants to realize the relationship in order to apply a client (== partner) specific policy to all instances or to present the end user with a tree like view in user self care, like this
My EPG Epg on iPhone Epg on Nexus One regards, Torsten. Am 27.07.2010 um 18:39 schrieb Marius Scurtescu <mscurte...@google.com>: > Is there value in pre-registering a binary that gets distributed? How > is this better than this application acting anonymously? > > At some point it was suggested that applications that are distributed > could do automatic registration of each instance, at which point they > are also issued a secret. During this registration step they can > specify an instance specific client name. > > It could be more important to have an instance specific client id, > than an instance specific client name. > > Marius > > > > On Tue, Jul 27, 2010 at 6:35 AM, Justin Richer <jric...@mitre.org> wrote: >> 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
