Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 17 June 2010 11:31 UTC

Return-Path: <torsten@lodderstedt.net>
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 4EB653A6A4D for <oauth@core3.amsl.com>; Thu, 17 Jun 2010 04:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
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 IhWY3X+bFVSS for <oauth@core3.amsl.com>; Thu, 17 Jun 2010 04:31:11 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 3C4413A69DD for <oauth@ietf.org>; Thu, 17 Jun 2010 04:30:28 -0700 (PDT)
Received: from cust.dyn.95-152-108-150.swisscomdata.ch ([95.152.108.150] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OPDIc-0000ry-Dv; Thu, 17 Jun 2010 13:30:22 +0200
Message-ID: <4C1A074F.40204@lodderstedt.net>
Date: Thu, 17 Jun 2010 13:30:23 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <AANLkTilRireowt1v8SidOiMJ-7ilBfvSqAiNfecA7uwR@mail.gmail.com> <4BFC371A.5040109@lodderstedt.net> <AANLkTikF1wk5eqme-N4RHviB5M7HzGYzy0p1mGuaux5g@mail.gmail.com> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <AANLkTils4bwYtv5u9yXJycqTQ_NFt0BUtA7P0kBTITpX@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimTIJBGrRl-vTihtzRZSHf0PflNmCZ74xudJYax@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1126411A9EB@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------020501060304070805070105"
X-Df-Sender: 141509
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization 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: Thu, 17 Jun 2010 11:31:14 -0000

I'm going to write an I-D for multiple access tokens. If someone else 
would like to contribute, please contact me.

regards,
Torsten.

Am 17.06.2010 03:56, schrieb Eran Hammer-Lahav:
>
> This use case seems to have some support for an extension, but enough 
> resistance for being added to core. I suggest those who care about 
> this write a proposal as an I-D.
>
> EHL
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
> Behalf Of *Manger, James H
> *Sent:* Wednesday, June 16, 2010 6:54 PM
> *To:* Breno
> *Cc:* OAuth WG (oauth@ietf.org)
> *Subject:* Re: [OAUTH-WG] proposal: multiple access tokens from a 
> single authorization flow
>
> Breno,
>
> > Alternative proposal. Create a new call for 'dropping privileges' 
> where a client can present a single refresh token and scopes and 
> obtain a new refresh token/access token with defined scopes provided 
> that these scopes were already granted to the original token.
>
> > The advantage of a separate call is that it has less impact in 
> implementations because it does not modify existing flows. It is also 
> more flexible. For instance it would allow a client too split its 
> privileges into tokens with overlapping scopes for arbitrary 
> requirements around security and functionality of delegating its 
> privileges.
>
> This alternative (dropping privileges) could work for clients that 
> know everything about a service: which scopes are necessary & 
> sufficient for each call, and that ‘dropping privileges’ is supported. 
> It requires lots of service-specific knowledge in the client, and/or 
> some reasonably sophisticated discovery (which is so far undefined, 
> untried, and not obvious how it should be done). A service that 
> *requires* dropped privileges can only reject calls that use full 
> tokens (and hope that hasn’t already compromised security), and hope 
> that clients can then discover how to drop privileges and what to drop 
> them to (efficiently & simply).
>
> Returning multiple tokens, in contrast, enables a server to say use 
> these (“pre-dropped”) tokens at these API endpoints. No extra 
> discovery is required. No extra service-specific knowledge is required 
> of clients.
>
> ‘Dropping privileges’ is nice additional functionality, but I don’t 
> think it is a good alternative to returning multiple tokens.
>
> -- 
>
> James Manger
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>