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

William Denniss <wdenniss@google.com> Thu, 31 May 2018 00:06 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 30E2A12EBD5 for <oauth@ietfa.amsl.com>; Wed, 30 May 2018 17:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.25
X-Spam-Level:
X-Spam-Status: No, score=-17.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 gPIh3tR-8cnc for <oauth@ietfa.amsl.com>; Wed, 30 May 2018 17:06:51 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 B5D8512EBC5 for <oauth@ietf.org>; Wed, 30 May 2018 17:06:50 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id n134-v6so12244145vke.12 for <oauth@ietf.org>; Wed, 30 May 2018 17:06:50 -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=zhvObqCM4eGIrjUTUA33F3rutCiwW3t/LO2twMSxDk0=; b=bv/A+zjIdjfD4PthMpNM3FBPtxw2MvX9QBDOP7EYq5e4xwkJ1ejjeD88zHgnjbIqTC dwkBf0lEdVa6980+J5QhZc5Y6sbV5Vm+346skAC2v67iNtUFTorupcT9SCIvw3M+MYor BQGY9CQmo25zK46vmwe2d68I0yJMI85s5Lwyoix6FEUj6NY6q1rIitjwgC0R915TxtCW xhO9HCTcbTcyfe+69ym7c6qVnLmJh5ogNMkCWnIPGerybKzyXIMH8jqPtxcNxGmWeMWm hl1Gj1sdUThK87IyfF+gLaFjIfffKEcvLyD+HrLCXMBSJslK7IBU1N2HZmtD4y+wmyA9 Esaw==
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=zhvObqCM4eGIrjUTUA33F3rutCiwW3t/LO2twMSxDk0=; b=MR4eHgMNhXAFh2tGzBXCLCShHunq9bMPzmelDZrN4smg1df/H3Qu0jYBeIPIu1+9z0 uWKy1hezz7Ch0EAR713rvqlKXO82tNHLO3v3voZkPWpzMEVJUMy/NdaF4CXQAYlaxT80 mUVFiTOv3Hr6axrWFZUS2PFP3SVThHkjesvRG7vll5sAGffB/xbHuWX71HfrqkW7smX9 1kd6Kf5AnOxq5mnx7p7irXNVUYdBFgpbUSqV7x8FcKINTB/x6HYNKug3EEgDMqMpGitB tq9px9vsIVHewdymNqwH8fa1i+wDgem+rNrGMoAl4CAI3+ufOvDQakqH6Ok0F3/ajlXe /7gw==
X-Gm-Message-State: ALKqPwcwanQl8/PSRLZ43kiE/GN8hwN0QkfXksaSBNw/ockXoxzLM5M/ HhqVRTRtaICJmGQQIrqrc/BP1tonGGqb0xMgd97RoQ==
X-Google-Smtp-Source: ADUXVKJmbB/mFjiHbnx+4fakWwfwnQxVJQH5yuV5YJVx8RLrvjkm/A9i7sWbOlca+b61mVZVmOBfwGqqP/QdaCZ/7Qg=
X-Received: by 2002:a1f:830b:: with SMTP id f11-v6mr2844505vkd.152.1527725209107; Wed, 30 May 2018 17:06:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Wed, 30 May 2018 17:06:28 -0700 (PDT)
In-Reply-To: <CA+k3eCQ5xxj4nCUBvQn1QwUEL-ouLiZgean02rFwEjC6dcz9mw@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>
From: William Denniss <wdenniss@google.com>
Date: Wed, 30 May 2018 17:06:28 -0700
Message-ID: <CAAP42hAwPdvNX1Hr=dvPwghQcP_iHvbHvS_aXtKGf1uGfLidSw@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.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="00000000000067e6fb056d753e94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cDp12g-nwUXzNV2LQnFOQ54Dot4>
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
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, 31 May 2018 00:06:54 -0000

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?


>
> On Wed, May 30, 2018 at 4:27 PM, William Denniss <
> wdenniss=40google.com@dmarc.ietf.org> wrote:
>
> > Hi Andrew,
> >
> > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> > andrewsciberras@pingidentity.com> wrote:
> >
> >> Hi William
> >>
> >> You are right that the document explicitly indicates which error codes
> >> may be returned. However I think it's ambiguous as to which error within
> >> Section 5.2 of RFC6749 would apply in the scenario of a user not
> granting
> >> access.
> >>
> >> I think that this ambiguity is highlighted further by the Google
> >> implementation (https://developers.google.com
> >> /identity/protocols/OAuth2ForDevices#step-6-handle-
> >> responses-to-polling-requests
> >> <https://developers..google.com/identity/protocols/OAuth2For
> Devices#step-6-handle-responses-to-polling-requests>)
> >> not adhering to the explicit statement of the document and electing to
> use
> >> a (more appropriate) error code that exists outside of section 5.2.
> >>
> >>
> >
> > Oh, I see what you mean now. Yes, given this is an authorization request,
> > not a token request, the errors from Section 4.1.2.1
> > <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more relevant.
> >
> > I believe it was the authors intention to reference that set of errors,
> so
> > I will plan to update the doc to reference 4..1.2.1 instead.  Good catch!
> > Thank you.
> >
> >
> >>
> >> On Thu, May 31, 2018 at 8:06 AM, William Denniss <wdenniss@google.com>
> >> wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <
> andrewsciberras@pingidentity.com> wrote:
> >>>
> >>> Hello
> >>>>
> >>>>
> >>>> Do we feel that the document should be more specific in addressing how
> >>>> the authorization service should respond to a device access token
> request
> >>>> when the user has refused to grant access to the device?
> >>>>
> >>>>
> >>>> The document currently indicates in section 3.5 that a success
> response
> >>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2
> of
> >>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant,
> >>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a
> new
> >>>> device flow error code (authorization_pending, slow_down, and
> >>>> expired_token) may be returned in a response to a device token request
>