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

From: Jaap Francke <[email-masked]>
Date: Fri, 7 Jul 2017 06:33:34 +0000

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

---

From: Justin Richer <[email-masked]>
Date: Fri, 7 Jul 2017 07:54:13 -0400

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

On 7/7/2017 2:33 AM, Jaap Francke wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth