Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

Brian Campbell <bcampbell@pingidentity.com> Thu, 31 May 2018 16:50 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B5112EC2F for <ietf@ietfa.amsl.com>; Thu, 31 May 2018 09:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 nDHmvxzrR1Ug for <ietf@ietfa.amsl.com>; Thu, 31 May 2018 09:50:16 -0700 (PDT)
Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 19A3512DA4A for <ietf@ietf.org>; Thu, 31 May 2018 09:50:07 -0700 (PDT)
Received: by mail-qt0-x242.google.com with SMTP id m5-v6so28681052qti.1 for <ietf@ietf.org>; Thu, 31 May 2018 09:50:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ahsGHJ1QWdO4abM498bbFD+dGLFBrKqAx9QNyG41x+g=; b=TInNo+yWpmIrTQvIJKVGpaja84VUWOS3iFnnz3vn1j7WThsmn+GMe81ZCEKo8kR9gX CZqh+CIqBaUKznDni16QxD7LYPQmVn9LkO6cUfosniVxxEWZo8sr0omO5HH65qZMdzhX LF9lXWb9YCUm5cKZJEmCXJwjhYqrLgb4g1mtI=
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=ahsGHJ1QWdO4abM498bbFD+dGLFBrKqAx9QNyG41x+g=; b=Z8sIjazWQXquPYow4bAZ6rAUOp/PdbwyewL+uX97zQiy/1p1S4Se7rhpglKVGMxP3Z /Kt535fwwgnOTNMqsFCP3/LcIFjz6cCOacHL7pXjWaqvKLqjHV3Qn2mDmVoWveghR7hJ v7DN75EHdzHc9+YRiOUzaBx/skw9BubGQYunNW0W87GGbDk+s64fu5woQLGaRaoN4psY QaD9c4aArSEU7kQVcd9h4t9LFXN2hNV0TQ88KghGvmXXTiRFLkDnpJ8nb7NK+TUPTKKY WQkxOgUb82cC9LSxdoyrGL+HCMG0nlIvDlPc6FWio6H6adovyjudLKPQe0g6et7/a2Ie rteg==
X-Gm-Message-State: APt69E3zHIoP7833MWMKKe9NCh2Mvyz2xyrp/CyRHo6Ay/0gGnkKOlUj XdDnxzwtnlZkxqYRLwKujwNa/T852ijJn9s4uNB6WgUeKibrK1TUE7qdrkrdM9jejjDNcdCMwl3 WjMb79UtChxUoRf0=
X-Google-Smtp-Source: ADUXVKLyG7Uu5aVBZ+FfN9RiVoeEVoRTdur/QeM8t8YrafYaVCishzf8+Sxitge7jHRIb/XfZpMEggIJA40mPIyBx0I=
X-Received: by 2002:ac8:1ca:: with SMTP id b10-v6mr7372750qtg.360.1527785406051; Thu, 31 May 2018 09:50:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:aed:22e1:0:0:0:0:0 with HTTP; Thu, 31 May 2018 09:49:35 -0700 (PDT)
In-Reply-To: <CAAP42hAwPdvNX1Hr=dvPwghQcP_iHvbHvS_aXtKGf1uGfLidSw@mail.gmail.com>
References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> <CAEqOSkfwdn-+1zFBgpgk3Mr6HYy-OvKNdVRKZtdP9c6HVHC60Q@mail.gmail.com> <CAAP42hAA8FC8B8bhDdCAg=5TnDjZXr76UiMLNABEG23GRFdeyQ@mail.gmail.com> <CAEqOSkcquQ4GXhhOV30TsOEYSV5fuG_PtO7TFo_pE_zVAJd0zA@mail.gmail.com> <CAAP42hBznvLPe8JLy1HYxFQ2bWxGW5mbpa8hcAv6K8jM3EkQxw@mail.gmail.com> <CA+k3eCQ5xxj4nCUBvQn1QwUEL-ouLiZgean02rFwEjC6dcz9mw@mail.gmail.com> <CAAP42hAwPdvNX1Hr=dvPwghQcP_iHvbHvS_aXtKGf1uGfLidSw@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 31 May 2018 10:49:35 -0600
Message-ID: <CA+k3eCQH_+a4duxo1q3zXPAsYOpVLnBcx5c09xTg4w1GJuP-0w@mail.gmail.com>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard
To: William Denniss <wdenniss@google.com>
Cc: William Denniss <wdenniss=40google.com@dmarc.ietf.org>, Andrew Sciberras <andrewsciberras@pingidentity.com>, draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, ietf@ietf.org, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006bd1c2056d834205"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wi7zcdY5TUFD7iZ9w7j__Y8-ALs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2018 16:50:28 -0000

On Wed, May 30, 2018 at 6:06 PM, William Denniss <wdenniss@google.com>
wrote:

>
> On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <
> bcampbell@pingidentity.com> wrote:
>
>> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
>> works given how RFC 6749 set things up. Rather I believe that the device
>> flow needs to define and register "access_denied" as a valid token
>> endpoint
>> response error code (it's not a token endpoint response error per RFC 6749
>> sec 5.2 nor has it been registered https://www.iana.org/assignmen
>> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error
>> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>
>> ).  Also
>> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2
>> so
>> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
>> <https://tools.ietf.org/html/rfc6749#section-4.1.2> defines errors
>> returned
>> from the authorization endpoint. But the device flow errors are from the
>> token endpoint.
>>
>>
> Yes, that's true. It's still the token endpoint, so 5.2 does in fact
> apply, it's just we're mixing in authorization-style actions which were not
> previously considered/used for that endpoint.
>
> Do you have any proposed text to resolve this?
>
>

Sure, here's a crack at some text/changes:


Add this to the list of error codes in section 3.5.:

        "access_denied
               The end-user denied the authorization request."


And add this to section 7.2.1.:

  "o  Error name: access_denied
   o  Error usage location: Token endpoint response
   o  Related protocol extension: [[ this specification ]]
   o  Change controller: IETF
   o  Specification Document: Section 3.5 of [[ this specification ]]"


I might also slightly change this text in section 3.5:

"In addition to the error codes defined in Section 5.2 of [RFC6749],
   the following error codes are specific for the device flow:"

to

"In addition to the error codes defined in Section 5.2 of [RFC6749],
   the following error codes are specified by the device flow:"

so that the wording doesn't read as prohibiting the error codes from being
used outside the device flow (access_denied from the token endpoint might
well be useful for other grant types).


And add "Andrew Sciberras" to the Acknowledgements.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._