Re: [OAUTH-WG] Draft -12 feedback deadline

Skylar Woodward <skylar@kiva.org> Thu, 27 January 2011 10:33 UTC

Return-Path: <skylar@kiva.org>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C5628C10C for <oauth@core3.amsl.com>; Thu, 27 Jan 2011 02:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJQjyfeY61gH for <oauth@core3.amsl.com>; Thu, 27 Jan 2011 02:33:58 -0800 (PST)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by core3.amsl.com (Postfix) with SMTP id F32B43A6961 for <oauth@ietf.org>; Thu, 27 Jan 2011 02:33:57 -0800 (PST)
Received: from source ([209.85.161.50]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTUFKy9+S+vDovUGpvIoH/OHcJHj6DiWz@postini.com; Thu, 27 Jan 2011 02:37:01 PST
Received: by fxm14 with SMTP id 14so2129914fxm.9 for <oauth@ietf.org>; Thu, 27 Jan 2011 02:36:58 -0800 (PST)
Received: by 10.223.72.10 with SMTP id k10mr744110faj.31.1296124618491; Thu, 27 Jan 2011 02:36:58 -0800 (PST)
Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id n3sm5899685faa.29.2011.01.27.02.36.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 02:36:57 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Skylar Woodward <skylar@kiva.org>
In-Reply-To: <AANLkTinMjQW26mLkoN7oMdLWLGAHp0_O9LbVi13RpMJB@mail.gmail.com>
Date: Thu, 27 Jan 2011 11:36:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7614CE6-BA5B-4E2E-9ECE-7CBF06DC527C@kiva.org>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinMjQW26mLkoN7oMdLWLGAHp0_O9LbVi13RpMJB@mail.gmail.com>
To: Marius Scurtescu <mscurtescu@google.com>
X-Mailer: Apple Mail (2.1082)
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 27 Jan 2011 10:33:59 -0000

On Jan 26, 2011, at 9:09 PM, Marius Scurtescu wrote:

> - 4.1. Authorization Code. It is stated that authorization code is
> suitable for clients that can hold a secret. Not necessarily true, it
> is the best flow for native apps, for example.

We concur with this as well. Our current implementation supports the auth flow for apps that can and cannot keep secrets (and our developer UI makes a clear distinction between these two in app registration). While most native apps should be able to perform a Implicit Grant flow, it helps to make permissible Auth Code flow as it allows a developer to reuse a flow with which he's already familiar. That is, Auth Code flow becomes the default flow with which developers will familiarize themselves with - the question is just whether or not an client credentials are required on token request.

I actually can't think of a case as Marius suggest where an Auth Code flow is better than Implicit for a native app, except for the point about reusing existing developer knowledge.  However, we do have the issue of the Out-of-Band flow (which is an important issue for us) which I'll address below.


-- 3.1.1, 4.1.2, and Out-of-Band flows

It is an important consideration for us that clients that cannot capture a redirect from the user-agent be able to use authentication flow. In the past this has been dubbed and Out-of-Band (OOB) flow. However, the reorganization of the document clearly marks out both Auth and Implicit as flows reserved for clients "capable of receiving incoming requests (via redirection) from the authorization server."  This language makes these incompatible with OOB clients.  In addition, other language inhibits this use:

- 3.1.1 definition of the redirection URI, requirement as an absolute URI, and other requirements of use
- restriction of 4.1 flow to clients that can keep secrets (eg, excludes OOB device clients)

Originally we had planned on the auth-code flow with a redirect_url of "oob" for such clients. Given the revised language, we'd likely avoid this now. Perhaps I missed considerations for OOB going forward.  If not, and short of revising the language in 4.1 to accommodate OOB, I assume the best path forward is an extension to section 4 as a consideration for clients that can't receive such incoming redirect requests.  Such a flow would be nearly identical to Auth Code but without the requirement of a redirect UI, open to clients without credentials, and a response_type of "oob_code."


-- Other feedback on flow-based reorganization.

The clear delineation of flows for clients with secrets and those without is the most spectacular improvement to the spec since v10, in my opinion. This includes Section 2 on Client Auth as well as the designation of the Auth Code flow for clients with credentials, and the restriction of the Implicit flow for those without. We consider this critical to a proper understanding of the protocol and how it should be used.

However, considering the Auth Code mechanic can be used without client auth as well, consider the following re-statement of client auth considerations for 4.1 and 4.2  (addition of terms "Verifiable" and "Forgeable" optional and open to editorial, of course)

1.3.5  Verifiable Client - a client that can keep secrets and can authenticate with the authorization server.  Examples include..
1.3.6  Forgeable Client - a client whose identity cannot be verified because the client is unable to keep authentication credentials secret.  Examples include...

4.1 Authorization Code

This flow is suitable for VERIFIABLE and FORGEABLE clients. As a redirection based protocol...

4.1.3
The authorization server MUST:
- Validate client credentials for VERIFIABLE clients.

4.2 Implicit Grant

This flow is suitable only for FORGEABLE clients.  As a redirection based protocol...