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
