[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
- [OAUTH-WG] Alternative Upgrade Flow Justin Richer
- Re: [OAUTH-WG] Alternative Upgrade Flow Marius Scurtescu
- Re: [OAUTH-WG] Alternative Upgrade Flow Justin Richer
- Re: [OAUTH-WG] Alternative Upgrade Flow Torsten Lodderstedt
- Re: [OAUTH-WG] Alternative Upgrade Flow Marius Scurtescu
- Re: [OAUTH-WG] Alternative Upgrade Flow William Mills