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
