Re: [OAUTH-WG] Device Code expiration and syntax

William Denniss <> Sat, 11 March 2017 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F5BA1295C3 for <>; Sat, 11 Mar 2017 12:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Q4xmiMvTWtM for <>; Sat, 11 Mar 2017 12:54:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A46F71295BF for <>; Sat, 11 Mar 2017 12:54:38 -0800 (PST)
Received: by with SMTP id i34so10723730qtc.0 for <>; Sat, 11 Mar 2017 12:54:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mhmWg3+6Cg/DtMxvNBqJtmLsiJM5YIH8inWNo5eriWw=; b=wQnDteCXQQWMeq1EuGzlck+RgWNW6qkjv31mSYK1YlcdPOjSU7cZXHZoMt5qtO3os/ HhXH1bz0FWGSCLMvgfRmSr7Zqe6u9DCpYjLmA7lJWkFjiuLK/UojQUz/x5XduXLlqBaE zbVuLdzqsNMFFU56LzzGaU3g24oL8aEUZ39wz1Ne/3W1PbacNQ5kD/LS1Fdot94dyUuB lkrBpPvRK0NG59L7shMGj6ycRQzSK1kq1VKjiogRKtPHaQ+NThr90Luq6CnizD0PSWNF t6oPIseKGHLlS2XGZ60F3d8qiFM6WTXOMBl3NY5OM/V2Z1znY3R75UNDSGCYzZVAniIO y9gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mhmWg3+6Cg/DtMxvNBqJtmLsiJM5YIH8inWNo5eriWw=; b=SWXFVaDPFbBv6ZUlCU1ZZYQ0QiWhm6e1QCFWJVDPXzTffnGBOwn4W12zVrngjfcZqn f+ENUJ5Ur9Vty7mffUxBQAtdGtn2ySRL/FR32yW6l9LUQxAAapGJOOOyvNClEhLIXaUx 5OAnSdHVfmq8XtD/mx2V3UFtnlSjKIANCbSxwUg9tPoJLm6DPk++MeizjfraS7XUwxJU u4cdACOa0s6GnuQOT5Im8xto8wqcwM242dWzPiLMksj0Pnc+LFu0T7sLgskP9sWs1axr FSGPMvSd1L6Mmq5qptTRXBrYlENwMIMeLDqiLfLByEepsACCMiROCJq2E3ZbIJ0Dz77T L8dQ==
X-Gm-Message-State: AMke39le5QJkxBbdUVRkIhRqWHwStWFtAuAYUQlTXJ0x4jmn3kL5fJupe15+iomoE8TsS5bpPek3gnHWtSszmG6G
X-Received: by with SMTP id v40mr27259312qta.80.1489265677474; Sat, 11 Mar 2017 12:54:37 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 11 Mar 2017 12:54:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: William Denniss <>
Date: Sat, 11 Mar 2017 12:54:17 -0800
Message-ID: <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="001a113a15e8af1fda054a7aafa3"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Device Code expiration and syntax
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Mar 2017 20:54:40 -0000

On Sat, Mar 11, 2017 at 12:40 PM, Justin Richer <> wrote:

> On Mar 11, 2017, at 2:54 PM, William Denniss <> wrote:
> On Sat, Mar 11, 2017 at 11:10 AM, Justin Richer <> wrote:
>> We’re implementing support for the device code draft and had a question
>> on what the “expiration” of the code refers to. Obviously, once the code
>> has expired it can no longer be used. But when should the expiration count
>> from? Say I have a code that’s good for 60 seconds, do I start the timer as
>> soon as I issue the code to the client? Do I reset the timer when the user
>> approves the client, to another 60 seconds? Or does that 60 seconds count
>> for the entire transaction?
>> My read on it is the latter-- one timeout for the entire lifetime of the
>> code regardless of its current state, with no resets. But I didn’t find
>> good guidance in the document itself.
> It's the expiry of the user_code and device_code pair, at which point the
> device will need to start-over with a new device authorization request.
> The device wouldn't *have* to start a timer, as they will get an error
> during polling:
>    expired_token
>       The "device_code" has expired.  The client will need to make a new
>       Device Authorization Request.
> We should add some guidelines around expiry behavior.
> OK, so it really is one expiration for the whole thing. The device doesn’t
> need to care (and I’ll bet you right now that, just like with access
> tokens, the overwhelmingly vast majority of devices won’t care about
> expires_in), but the authorization server certainly does, and we wanted to
> know the right place to set the timers.
You're probably right that most ignore expires_in, and I think that's fine.
As long as the client handles errors correctly, it'll work out OK.

Agree that we should add some documentation. One piece of advice for the AS
would be not to make it too short, else users won't be able to complete the
flow in time.

We use a 30 minute expiry.

> Secondly, I had a question about the “response_type” parameter to the
>> device endpoint. This parameter is required and it has a single, required
>> value, with no registry or other possibility of extension. What’s the
>> point? If it’s for “parallelism”, I’ll note that this is *not* the
>> authorization endpoint (as the user is not present) and such constraints
>> need not apply here.
> Good points here. At a guess, it bled in from the OAuth spec. If it's not
> needed, we should remove it.
> I’d vote for removal, I don’t see the point.
>  — Justin