IETF Logo Mail Archive

Re: [OAUTH-WG] Alternative Upgrade Flow

"William Mills" <wmills@yahoo-inc.com> Mon, 19 July 2010 15:58 UTC

Return-Path: <wmills@yahoo-inc.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 8DB583A6914 for <oauth@core3.amsl.com>; Mon, 19 Jul 2010 08:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.164
X-Spam-Level:
X-Spam-Status: No, score=-17.164 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15]
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 kCx58MKTKJeS for <oauth@core3.amsl.com>; Mon, 19 Jul 2010 08:58:33 -0700 (PDT)
Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 70F483A688F for <oauth@ietf.org>; Mon, 19 Jul 2010 08:58:33 -0700 (PDT)
Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o6JFwcf3012528; Mon, 19 Jul 2010 08:58:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=WdaN5lfA2n+y5fMD8BaRe5Z4DF5cV+gaaQRAd4e7EB+Xa8VbCyes4PXmy5wBt2r0
Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 08:58:38 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Jul 2010 08:58:36 -0700
Message-ID: <012AB2B223CB3F4BB846962876F47217059B6D4F@SNV-EXVS08.ds.corp.yahoo.com>
In-Reply-To: <4C41A281.7080809@lodderstedt.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] Alternative Upgrade Flow
Thread-Index: Acslq/9X9MKrbFU2R8aX7gJxE3xkjQBrxDBA
References: <1279298904.11628.74.camel@localhost.localdomain> <4C41A281.7080809@lodderstedt.net>
From: William Mills <wmills@yahoo-inc.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>, Justin Richer <jricher@mitre.org>
X-OriginalArrivalTime: 19 Jul 2010 15:58:38.0395 (UTC) FILETIME=[4044D0B0:01CB275B]
Cc: oauth@ietf.org
Subject: Re: [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: Mon, 19 Jul 2010 15:58:34 -0000

Seems like we could also simply put up a 1.0a PR that issues a 2.0
token.  That avoids wedging 1.0 stuff into 2.0. 

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 
> On Behalf Of Torsten Lodderstedt
> Sent: Saturday, July 17, 2010 5:31 AM
> To: Justin Richer
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Alternative Upgrade Flow
> 
> I think we gonna need additional end points anyway, e.g. for 
> token revocation. So why not use another endpoint for that 
> purpose? That way the tokens endpoint is not overloaded to much.
> 
> regards,
> Torsten.
> 
> Am 16.07.2010 18:48, schrieb Justin Richer:
> > 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 mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >    
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.35.0 | Report a Bug | By Email | System Status