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

[Jaap Francke]

Hi all,

Recently we were working with one of our customers to implement the device flow as part of our IDaaS.
One of the requirements was the ability to revoke tokens for one of the devices at the Resource Server.

In our use case, we used the terminolgy ‘pairing a device to the enduser’s account’ to describe the process of authorising a device to access the resource owner’s resources.
The resource owner may want to ‘unpair’ a device from a list of paired devices without having access to the device itself (anymore). Think about a stolen/lost kind of situation.
We are looking for ways to allow the user to unpair one of his devices at the Authorisation Server.
Since the Device Flow exchanges only the ‘generic’ client_id with the Authorisation Server, there is no logical way at the Resource Server to make a distinction between various devices (having the same client_id) that may be paired to the same Resource Owner.

My suggestion is the following
- add an optional parameter to the device authorisation request (or device access token request): 'device_identifier'. A device can use this to make (for example) its serial-number known at the Resource Server.
- add an optional parameter to the device access token response that allows to communicate a name for the device as may have been given to it by the resource owner while allowing the clients access (E). This parameter could be something like ‘device_name’. The device may be able to display this ‘device_name’ on its display.

Please consider this as a suggested enhancement of the Device Flow specifications.

Kind regards,

Jaap Francke
Product Manager, iWelcome

[Justin Richer]

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

Post by Jaap Francke
Hi all,
Recently we were working with one of our customers to implement the device flow as part of our IDaaS.
One of the requirements was the ability to revoke tokens for one of the devices at the Resource Server.
In our use case, we used the terminolgy ‘pairing a device to the enduser’s account’ to describe the process of authorising a device to access the resource owner’s resources.
The resource owner may want to ‘unpair’ a device from a list of paired devices without having access to the device itself (anymore). Think about a stolen/lost kind of situation.
We are looking for ways to allow the user to unpair one of his devices at the Authorisation Server.
Since the Device Flow exchanges only the ‘generic’ client_id with the Authorisation Server, there is no logical way at the Resource Server to make a distinction between various devices (having the same client_id) that may be paired to the same Resource Owner.
My suggestion is the following
- add an optional parameter to the device authorisation request (or device access token request): 'device_identifier'. A device can use this to make (for example) its serial-number known at the Resource Server.
- add an optional parameter to the device access token response that allows to communicate a name for the device as may have been given to it by the resource owner while allowing the clients access (E). This parameter could be something like ‘device_name’. The device may be able to display this ‘device_name’ on its display.
Please consider this as a suggested enhancement of the Device Flow specifications.
Kind regards,
Jaap Francke
Product Manager, iWelcome
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Jaap Francke]

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
Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
Content-Type: text/plain; charset=utf-8; format=flowed
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

[William Denniss]

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

Post by Jaap Francke
Hi Justin,
Thanks for your reply.
I had missed your proposal, but it’s indeed the same line-of-thought.
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
Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
Content-Type: text/plain; charset=utf-8; format=flowed
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

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth