Subject: [OAUTH-WG] Moving the User Experience Extension draft forward

From: David Recordon <[email-masked]>
Date: Mon, 12 Jul 2010 12:51:13 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Jul 2010 13:26:48 -0700

Now that core is pretty stable, we should start adding a few new WG items. This is a no brainer.

EHL

On 7/12/10 12:51 PM, "David Recordon" <[email-masked]> wrote:

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

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 13 Jul 2010 10:49:43 +1000

.David,

> I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a working group document

I disagree. This shouldn't be a working group document. It should be moved into the core.

The 2 parameters it defines (language and display) should be moved to the core OAuth doc now they have obtained some consensus (for which a separate draft was helpful).

I suggest a sub-section of section 3 "Obtaining End-User Authorization" (of the core spec) for user interface parameters.

Possible structure:

3. Obtaining End-User Authorization

  [keep most of the existing paragraphs, except the definitions of the 5 parameters]

  [Add a paragraph saying various query parameters can be added to the end-user authorization URI to provide details or preferences about the style of response, the client application, the scope of access desired, the user, the user interface etc. Some parameters are defined in the following sub-sections. Other parameters can be defined by other specifications, or by services.]

3.1 Response style parameters

  response_type ...

  redirect_uri ...

  state ...

3.2 Client parameters

  client_id ...

3.3 User interface parameters

  language ...

  display ...

3.4 Scope of access parameters

  scope ...

--

James Manger

---

From: David Recordon <[email-masked]>
Date: Mon, 12 Jul 2010 19:31:10 -0700

Obviously I'm fine with this being merged into core if that's what the group
wants to do. :)

On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H <
[email-masked]> wrote:

> I disagree. This shouldn’t be a working group document. It should be moved
> into the core.
>
>
>
> The 2 parameters it defines (language and display) should be moved to the
> core OAuth doc now they have obtained some consensus (for which a separate
> draft was helpful).
>
>
>
> I suggest a sub-section of section 3 “Obtaining End-User Authorization” (of
> the core spec) for user interface parameters.
>
>
>
> Possible structure:
>
>
>
>   [Add a paragraph saying various query parameters can be added to the
> end-user authorization URI to provide details or preferences about the style
> of response, the client application, the scope of access desired, the user,
> the user interface etc. Some parameters are defined in the following
> sub-sections. Other parameters can be defined by other specifications, or by
> services.]
>
>
>
>   response_type …
>   redirect_uri …
>   state …
>   client_id …
>   language …
>   display …
>   scope …

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Jul 2010 19:36:45 -0700

I think it belongs in a separate spec (even if at the end if might mean more work for others and me). I don't think the UX bits are well understood or enjoy enough experience to become part of core. They also tend to change often as the state of the art in UX evolves.

With -10, I am going to take a general approach of objecting any new features in core unless you can show the spec cannot be used without them.

EHL

On 7/12/10 7:31 PM, "David Recordon" <[email-masked]> wrote:

Obviously I'm fine with this being merged into core if that's what the group wants to do. :)

On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H <[email-masked]> wrote:
.David,

Possible structure:

3.2 Client parameters
  client_id ...

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 13 Jul 2010 08:28:35 -0400

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: [email-masked] [[email-masked]] On Behalf Of David Recordon [[email-masked]]
Sent: Monday, July 12, 2010 3:51 PM
To: OAuth WG
Subject: [OAUTH-WG] Moving the User Experience Extension draft forward

Thanks,
--David

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Jul 2010 15:23:08 -0700

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. <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Jul 2010 12:48:20 +0200

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:
> On Tue, Jul 13, 2010 at 5:28 AM, Richer, Justin P.<[email-masked]>  wrote:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Jul 2010 12:51:51 +0200

If I understand your proposal correctly, you assume the clients knows 
better than the authz server how to fit the client presentation 
capabilities the best.

Wouldn't it be neccessary to also tell the authz server the screen 
orientation and available size?

regards,
Torsten.

Am 12.07.2010 21:51, schrieb David Recordon:
> 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
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 27 Jul 2010 09:35:31 -0400

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

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 27 Jul 2010 09:39:25 -0700

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Jul 2010 19:08:28 +0200

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.

---

From: Justin Richer <[email-masked]>
Date: Tue, 27 Jul 2010 13:31:29 -0400

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. 

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. 

 -- Justin

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 27 Jul 2010 11:38:42 -0700

> 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?

> human-readable, something that the client_id and its attendant bits have

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