On Tue, Jul 27, 2010 at 10:31 AM, Justin Richer <jric...@mitre.org> wrote: > The second use case I outlined is not a distributed app and does not fit > the case for dynamic registration at all. It is a server with a securely > stored and guarded secret. The same user can have multiple authorized > inputs (email addresses in this case) to this server, and all are stored > with separate tokens and require separate authorization steps. What we > end up with is a user having four instances of this app in their apps > list on the PR with no good way to differentiate between the instances.
I see, that's an interesting use case. On the client side the user can have multiple accounts or personae. You can have a many-to-many relationship between accounts on the client side and on the authz server side. Since there is no explicit support for this in oauth (something like client_user_account), I assume you would have to use the 'state' parameter to pass this information through? What about adding the notion of a client side user account? > While I'm all for allowing dynamic registration, I also don't see why > this couldn't be used to augment the information in a distributed > binary, whether the client_id be pre-registered, anonymous, or some kind > of user-agent-string. The idea behind the name is to make it something > human-readable, something that the client_id and its attendant bits have > no real business being. You are probably right, having client_name/client_description parameters that can be used in all flows and with all clients (not only unregistered) is useful. It is up to the authz server to use this info however it sees fit (even ignore for registered clients). Marius > > -- Justin > > On Tue, 2010-07-27 at 12:39 -0400, Marius Scurtescu wrote: >> 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
