Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E11B3108 for ; Fri, 13 Nov 2015 12:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 bxyHciRYF2O3 for ; Fri, 13 Nov 2015 12:46:50 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 6163D1B3107 for ; Fri, 13 Nov 2015 12:46:50 -0800 (PST) Received: by ioc74 with SMTP id 74so109326609ioc.2 for ; Fri, 13 Nov 2015 12:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hmqS7TksJ62OpKK37dZLdyxwWmGmLy84spx1QB2wCy4=; b=0D3IyE6hyLJKBvGYGjns7wSMvTL/hyPzwQuRH68h4tMpGH90pVR9rWN7Ge9bIUvFGO M94ngNKt0v3ITh9asr62Ko3bLMuXmn/AolQvfnTg2fswm5mxhSXNOlSom7uVSCzuRKJK jtiJLVWo6FY8iLFm02uTvK7KxvTCT/1JSno2xelA4d5ixYfLFpb7KAmtlhFhYdMNPGd0 liJKLQbcYKK4fXYKWqkivMTtbjGMB4k/5o+D+mtN4LO+YkM7Oe08CxiIZiqEmBIyKi2T nfW8639t2VxPaU+CTzEHqSTZnxULfXcRfjVYJyD+PCHOnCXOhY1H9TcXiSdItgaq7gVo GFkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hmqS7TksJ62OpKK37dZLdyxwWmGmLy84spx1QB2wCy4=; b=Cx6cY6LpCVYOEgYDQID5CaT0DLp/V0qkpMi1C19yObhprm0TpWy5rrVYmvqFzDLpyz zHVF6UrdBImjpZt+po8jztW3nR55uCvo8mZDsoHPt7XNEDj34xddue4SKD6xZiXANSWD u80tIZTmD3Tdvtgcd1GKqWFSJKDSIJhkwtzqgiqq4m1qA1TKU8rSGjIxKR+WVzMjSfda C4hbACVf58C+505+BCI7JYfFFS2OEkfCF7acJapBn9jKA6KQRFwqY1woZfyosZLYFJNh J+We5LKFtIcxI7ve6ww2ycsjSsC9mZ5PVTGtbmJYTGCxQpcKfuc+tRHhbgywkgHawAHt AOFw== X-Gm-Message-State: ALoCoQnZwX/ZlCbWKn4SHBF/sX456Ya+piZph7kw8yjjEP2iyGkxXpvnNn4xRPC0rSfmW6lwdVXM X-Received: by 10.107.148.8 with SMTP id w8mr11176192iod.3.1447447609686; Fri, 13 Nov 2015 12:46:49 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id n9sm1942998ige.16.2015.11.13.12.46.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 12:46:48 -0800 (PST) Received: by igbxm8 with SMTP id xm8so22064528igb.1 for ; Fri, 13 Nov 2015 12:46:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.61.232 with SMTP id t8mr5314265igr.16.1447447608559; Fri, 13 Nov 2015 12:46:48 -0800 (PST) Received: by 10.107.181.78 with HTTP; Fri, 13 Nov 2015 12:46:48 -0800 (PST) In-Reply-To: <563AA676.4060106@gmx.net> References: <563AA676.4060106@gmx.net> Date: Fri, 13 Nov 2015 12:46:48 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: "oauth@ietf.org" , Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7bdc05e88a1c5605247228aa Archived-At: Subject: Re: [OAUTH-WG] OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 20:46:52 -0000 --047d7bdc05e88a1c5605247228aa Content-Type: text/plain; charset=UTF-8 In reading this over, I noticed a subtle difference from the Facebook and Google implementations, and I'm wondering if this was intentional or not. Section 3.1 says "The authorization server prompts the end-user to authorize the client's request by entering the end-user code provided by the client." The introduction has even more explicitly different wording: "(D) ... If the end-user agrees to the client's access request, the end-user enters the end-user code provided by the client." However this is different from Facebook and Google's implementations, which work as follows: - Device shows the verification URI and code to the user - The user visits the URL and is prompted to sign in to the service (Google has the extra step of then choosing which Youtube account to use) - The user is then prompted to enter the device code - After entering the device code, the authorization prompt is displayed In reading this draft, the implication is that the act of entering the code also is the authorization. The problem is that the server won't know things like the scope or application name until after the code is entered, so it can't properly show an authorization prompt. I think this needs to be reworded to separate entering the code from showing the authorization prompt. I believe it is only a wording change. Maybe something more like: 3.1 "The authorization server prompts the end-user to enter the end-user code provided by the client, after which it prompts the end-user to authorize the client's request." and in the introduction: 1. (D) "The authorization server authenticates the end-user (via the user-agent) and prompts the end-user to enter the end-user code provided by the client. The authorization server validates the end-user code and prompts the end-user to grant the client's access request." ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig wrote: > FYI: A couple of us got together and re-published an old, expired draft > about the OAuth Device Flow. > > Here is the document: > https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 > > For the -00 version we tired to keep it inline with what has been > available with draft-recordon-oauth-v2-device-00. In upcoming versions > of this document we would like to capture existing deployment. > > Here are two deployment examples that are reasonably well described: > > - Google > https://developers.google.com/youtube/v3/guides/auth/devices > > - Facebook > https://developers.facebook.com/docs/facebook-login/for-devices > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bdc05e88a1c5605247228aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In reading this over, I noticed a subtle difference from t= he Facebook and Google implementations, and I'm wondering if this was i= ntentional or not.

Section 3.1 says "The authorizat= ion server prompts the end-user to authorize the client's request by en= tering the end-user code provided by the client." The introduction has= even more explicitly different wording: "(D) ... If the end-user agre= es to the client's access request, the end-user enters the end-user cod= e provided by the client."

However this is di= fferent from Facebook and Google's implementations, which work as follo= ws:
  • Device shows the verification URI and code to the use= r
  • The user visits the URL and is prompted to sign in to the service= (Google has the extra step of then choosing which Youtube account to use)<= /li>
  • The user is then prompted to enter the device code
  • After en= tering the device code, the authorization prompt is displayed
In r= eading this draft, the implication is that the act of entering the code als= o is the authorization. The problem is that the server won't know thing= s like the scope or application name until after the code is entered, so it= can't properly show an authorization prompt.

= I think this needs to be reworded to separate entering the code from showin= g the authorization prompt. I believe it is only a wording change. Maybe so= mething more like:

3.1 "The authorization ser= ver prompts the end-user to enter the end-user code provided by the client,= after which it prompts the end-user to authorize the client's request.= "

and in the introduction:

1. (D) "The authorization server authenticates the end-user (vi= a the user-agent) and prompts the end-user to enter the end-user code provi= ded by the client. The authorization server validates the end-user code and= prompts the end-user to grant the client's access request."
=

----
Aaron Parecki

On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tscho= fenig <hannes.tschofenig@gmx.net> wrote:
FYI: A couple of us got together and re-published an= old, expired draft
about the OAuth Device Flow.

Here is the document:
https://tools.ietf.org/html/draft-denn= iss-oauth-device-flow-00

For the -00 version we tired to keep it inline with what has been
available with draft-recordon-oauth-v2-device-00. In upcoming versions
of this document we would like to capture existing deployment.

Here are two deployment examples that are reasonably well described:

- Google
https://developers.google.com/youtube/v3= /guides/auth/devices

- Facebook
https://developers.facebook.com/docs/= facebook-login/for-devices

Ciao
Hannes


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--047d7bdc05e88a1c5605247228aa--