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
