Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow

From: Jaap Francke <[email-masked]>
Date: Tue, 11 Jul 2017 09:49:15 +0000

Hi Justin,

Thanks for your reply.

I had missed your proposal, but it’s indeed the same line-of-thought.
My proposal is slightly different in the sense that the device_name (or: instance_name) would not originate from the client itself but from the ResourceOwner, e.g. during the authorisation process.
This is probably specific or at least more relevant to devices with input constraints.

I understand the point about dynamic client registration. 
At a first glance it seems very ‘open’, whereas in a lot of case you wouldn’t want any client to register. 
Moreover, I feel that using dynamic client registration just for the sake of setting up identifiers for a client instance seems a bit ‘heavy’.
So I still feel it’s usefull to enhance the Device flow with something like: device_identifier / device_name / instance_name / instance_description

regards, Jaap

> Message: 2
> Date: Fri, 7 Jul 2017 07:54:13 -0400
> From: Justin Richer <[email-masked]>
> To: [email-masked]
> Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> I proposed this exact thing many years ago:
> 
> https://tools.ietf.org/html/draft-richer-oauth-instance-00
> 
> At the time there wasn't very much interest in it, as people were 
> looking at using Dynamic Registration, with its attendant unique client 
> IDs, to solve that same problem.
> 
>  -- Justin

---

From: William Denniss <[email-masked]>
Date: Thu, 20 Jul 2017 19:12:04 +0100

We'd thought of this too. In fact our param names are almost identical to
yours. Here is my list from last year:

device_id = a manufacturer device id so we can link apps on the 1 device in
order to present it as a single entity for revocation
device_model = the manufacturer's name, like "Roku 3" or "Chromecast"
device_name = user nickname e.g "William's Chromecast"

The point to ask for this information from the device would be to display a
better revocation page. If you have multiple Roku devices, it's nice to
know which one you want to disconnect (e.g. "Livingroom"). Also if you
authorized multiple different apps (with different client_ids) the
device_id can be used to revoke them all at once (great for the lost/sold
device case).

Since it seems the 3 of us thought of this independently, it's probably
worth adding to the discussion at IETF99 tomorrow. Will you join Jaap? it's
open to remote participants if you're not in Prague.

Justin, I like your more generic proposal to solve this for clients with
multiple instances. I think the use-case has morphed from unregistered
clients to native apps – but broadly the requirement is the same. I guess
there's no overlap with this (rather old) proposal since the Device
Authorization endpoint is technically a different endpoint to OAuth 2.0
(even if some param names and functions are shared), but if your draft were
to be ever be revived it might be nice to sync the param names. Do you see
that happening?

Jaap, I'm not sure how device and instance params are different in your
proposal, is that just capturing the difference between the model and the
user's custom name as I did with the _model and _name params here? The
client itself already has different metadata too, so different device
deployments can already register different clients.

William

On Tue, Jul 11, 2017 at 10:49 AM, Jaap Francke <[email-masked]>
wrote:

> My proposal is slightly different in the sense that the device_name (or:
> instance_name) would not originate from the client itself but from the
> ResourceOwner, e.g. during the authorisation process.
> Moreover, I feel that using dynamic client registration just for the sake
> of setting up identifiers for a client instance seems a bit ‘heavy’.
> So I still feel it’s usefull to enhance the Device flow with something
> like: device_identifier / device_name / instance_name / instance_description
>
> regards, Jaap
>
>
> > Message: 2
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>