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

Jaap Francke <jaap.francke@iwelcome.com> Tue, 11 July 2017 09:49 UTC

Return-Path: <jaap.francke@iwelcome.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C834912EB99 for <oauth@ietfa.amsl.com>; Tue, 11 Jul 2017 02:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X5bixpyDBGb for <oauth@ietfa.amsl.com>; Tue, 11 Jul 2017 02:49:19 -0700 (PDT)
Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBEA1242F7 for <oauth@ietf.org>; Tue, 11 Jul 2017 02:49:18 -0700 (PDT)
From: Jaap Francke <jaap.francke@iwelcome.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
Thread-Index: AQHS+ir1wad97hzRckuaQgYQihFwBQ==
Date: Tue, 11 Jul 2017 09:49:15 +0000
Message-ID: <8C513CFD-FDBE-4958-952A-6D518CA22627@iwelcome.com>
References: <mailman.5873.1499450208.31347.oauth@ietf.org>
In-Reply-To: <mailman.5873.1499450208.31347.oauth@ietf.org>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.17.5.138]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A64A3ADF9E149B46B75096BB311E71C3@enterexchange.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iIPtr-VUi0GNbWlICaMq7S-F5jQ>
Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2017 09:49:22 -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 <jricher@mit.edu>
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
> Message-ID: <71e43e3c-2bd3-d706-2c82-6020de8ff881@mit.edu>
> 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