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

William Denniss <wdenniss@google.com> Thu, 20 July 2017 18:12 UTC

Return-Path: <wdenniss@google.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 74D33131A69 for <oauth@ietfa.amsl.com>; Thu, 20 Jul 2017 11:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 dotS5ZstGFvk for <oauth@ietfa.amsl.com>; Thu, 20 Jul 2017 11:12:31 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D8D131B7A for <oauth@ietf.org>; Thu, 20 Jul 2017 11:12:26 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id b40so29245239qtb.2 for <oauth@ietf.org>; Thu, 20 Jul 2017 11:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E+O2pvWstuOmT3P0NJUonJKhWS9ki5YsjbDs44iJqW4=; b=rGhrSUwhXr87/KXRgzcNOytijoO0LZ0qiN/oXPZDu18GgC0VEPZ7pVA4YUlNT02d+u MAc1XB5xl4VQwxGEJTvIDgWJ7QstQPEdAe+q9dY4UATSegEJbMLBf1J4WaalOiryGsJX so9FpJU+pp78BR9Gfv9f9yvjxQb4XvCiSogAW3E+0vn2ftLqvTu9et7vPtxzV7AohtLW /yA2ulNM86u1jY0X+En9x1JY1lzrsVfVy399my97P5CBaZiwgZCH1+nky6zkaZLVSfOj taUAXnzyNOyxJLG1dAqRG3yxhESByCQaTuZFSYq67GcxL3aQ+VqZ1ZQROG87nistA2+a Cr5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E+O2pvWstuOmT3P0NJUonJKhWS9ki5YsjbDs44iJqW4=; b=AVQs/reJfQBKqK0LQHo5KRQRnMqiEqlEJ2JQcAzcXdDwuiMAf1IJVLdx67GSvKbtBS TrQ1kmuRyoSNp3h6gxROKzEAmKUo5GTg0dN0rr9kB8wX+hBkY+BSUj7V6CfvjoydJqhO gWNYoAtLL6dLF6O4sS5NAAlJNgmXcxDTFkfQHgVTeYN94dmoi8/0gxYkimn+7WAYCcgp gFdzvP0a6A4NnqFXGSo/iAI7EISDGurPFbjG5PP5hDFoVbXIcJfiIrhRo9MGmsNtCeyg fk2PdzkeBYglWytzypY3xJLIQJueGzUklsjPbg2DQvAQGiLevFzqwcmjvORsd6VcM6UL Xv5g==
X-Gm-Message-State: AIVw113BtUD/dvnCf+eYs6DllnU8FhzyJq2Ep912tjzV6ysYgVs0hpkV UjxW2n9JH8oi64sNiUUbR87IFm7nbQdnnFtdWQ==
X-Received: by 10.200.4.140 with SMTP id s12mr6279187qtg.35.1500574344953; Thu, 20 Jul 2017 11:12:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.18.144 with HTTP; Thu, 20 Jul 2017 11:12:04 -0700 (PDT)
In-Reply-To: <8C513CFD-FDBE-4958-952A-6D518CA22627@iwelcome.com>
References: <mailman.5873.1499450208.31347.oauth@ietf.org> <8C513CFD-FDBE-4958-952A-6D518CA22627@iwelcome.com>
From: William Denniss <wdenniss@google.com>
Date: Thu, 20 Jul 2017 19:12:04 +0100
Message-ID: <CAAP42hDW6ixH8pgGSKQMDOPF-x=eZNZrg++4R5KSivCiqjRn0Q@mail.gmail.com>
To: Jaap Francke <jaap.francke@iwelcome.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="f4030435b49ccaf5d10554c3b0b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/e1ox9bDE1cZ-EvoFEqAHItFxNyo>
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: Thu, 20 Jul 2017 18:12:35 -0000

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 <jaap.francke@iwelcome.com>
wrote:

> 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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>