Re: [OAUTH-WG] Native Client Extension

Marius Scurtescu <mscurtescu@google.com> Fri, 28 January 2011 00:41 UTC

Return-Path: <mscurtescu@google.com>
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 8AF673A6A0A for <oauth@core3.amsl.com>; Thu, 27 Jan 2011 16:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.004
X-Spam-Level:
X-Spam-Status: No, score=-105.004 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 9T0OqHwMF9mI for <oauth@core3.amsl.com>; Thu, 27 Jan 2011 16:41:58 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7753B3A6A08 for <oauth@ietf.org>; Thu, 27 Jan 2011 16:41:58 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p0S0j2xB012539 for <oauth@ietf.org>; Thu, 27 Jan 2011 16:45:02 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296175502; bh=Mh7K1o8Rp+WgmOXP3SDvju6o28k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=SYPVLYMKjcHCfjAASyevBu+yL/LXb7fZKvrCJgylEliMLWzlYc6xM4+qd5me0n6+i mun7Mt+L1gVYQY+6MVpOA==
Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by wpaz13.hot.corp.google.com with ESMTP id p0S0j0Ip007865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <oauth@ietf.org>; Thu, 27 Jan 2011 16:45:00 -0800
Received: by gxk10 with SMTP id 10so976174gxk.12 for <oauth@ietf.org>; Thu, 27 Jan 2011 16:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ghFEH+AA4lFgLkkz2zgHrNLnTgHA/jo9zwr/2zKo6BY=; b=Om8Lhd6nvSwpoge5Y1D+XeeS2tsR3r1rr9VTS0pyDJWtuSUO6XC3tpoJoLlVtuv2s1 Uz7TiVm1dtWfGhu5TaFQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=d0i1i0NszCc+HyGdmuy6SUZNKxhENKt3vs/PVsCso01WFGD3y7renRI09D4Q1Vuh6t de/BkRDfuXHgbfw9jTjg==
Received: by 10.100.164.2 with SMTP id m2mr1094770ane.146.1296175500096; Thu, 27 Jan 2011 16:45:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.153.9 with HTTP; Thu, 27 Jan 2011 16:44:39 -0800 (PST)
In-Reply-To: <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org>
References: <AANLkTi=YWLHV1Yi0bdKTaDaBw3X5D6Y_kk3xt7EvJHe_@mail.gmail.com> <4D239DCF.4030501@lodderstedt.net> <AANLkTi=RAS5X0jUjxFzf6k1_r+79NFSFjmZs2bw2Lg3o@mail.gmail.com> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Thu, 27 Jan 2011 16:44:39 -0800
Message-ID: <AANLkTin_=nJi7yeJ8VTMV-dufB8UoP5Y4r1ffM+82vgO@mail.gmail.com>
To: Skylar Woodward <skylar@kiva.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Native Client Extension
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: Fri, 28 Jan 2011 00:41:59 -0000

On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward <skylar@kiva.org> wrote:
> Marius,
>
> I support the extension (as per my previous letter, as I missed this thread over the holidays) and Kiva is/was planning to support this as well.  Given the unpredictable technology environments of many of our customers, this flow is essential for our implementation.
>
> However, now reviewing language in draft-12, I wonder if it isn't more clear to define the extension as using a different response_type (eg, oob_code).  In the past, the use of "oob" has been more of hack to work with existing specs. In truth, it is a unique flow of its own compared to Implict and Auth Code as they are currently defined.  Such a flow would not accept a redirect_url and could use "oob_code" for both response_type and grant_type.

I still think that "oob" applies only to the mechanism to return a
result, and not to the whole flow. Theoretically redirect_uri=oob
should work with both response_type=code and response_type=token, but
I had in mind only code.

Also, I don't see a reason to do anything special with the grant_type,
once the client has an authorization code it is all the same.

Marius