[OAUTH-WG] Alternative Upgrade Flow

Justin Richer <jricher@mitre.org> Fri, 16 July 2010 16:48 UTC

Return-Path: <jricher@mitre.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 938EE3A6ABD for <oauth@core3.amsl.com>; Fri, 16 Jul 2010 09:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.427
X-Spam-Level:
X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 oF6EF7+HSAts for <oauth@core3.amsl.com>; Fri, 16 Jul 2010 09:48:19 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 3656F3A6A0C for <oauth@ietf.org>; Fri, 16 Jul 2010 09:48:15 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GGmPm4009563 for <oauth@ietf.org>; Fri, 16 Jul 2010 12:48:25 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6GGmPmD009560 for <oauth@ietf.org>; Fri, 16 Jul 2010 12:48:25 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 16 Jul 2010 12:48:24 -0400
From: Justin Richer <jricher@mitre.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 16 Jul 2010 12:48:24 -0400
Message-ID: <1279298904.11628.74.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Alternative Upgrade Flow
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, 16 Jul 2010 16:48:28 -0000

The current proposal for a 1.0->2.0 upgrade flow is to use the assertion
profile and pass the OAuth token in there. Instead, one could create an
endpoint that speaks the 1.0 protocol fully, signatures and client
secrets and everything, but issues 2.0 tokens, JSON and all. It's a
hybridized endpoint also, but put together with the opposite pieces. In
both cases, you put a 1.0 token in one end and get a 2.0 token out the
other. But in this case, the request being made is a completely vanilla
OAuth 1.0 protected resource access request. 

Does this really need a separate endpoint, or can we extend the
grant_type options to include "oath1.0" in an extension? I know that
extensions aren't currently allowed to make new grant_types -- I think
they should be able to and and proposing that we allow that extension
point. I dislike the reasoning of "just cram it all into an assertion to
extend", since it doesn't allow for clients to separate out their
parameters easily.

 -- Justin