Re: [OAUTH-WG] Rechartering

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 26 October 2011 16:16 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5579B21F84C3 for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 09:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level:
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEl-y2CsmVJE for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 09:16:18 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 0C3BC21F84B6 for <oauth@ietf.org>; Wed, 26 Oct 2011 09:16:17 -0700 (PDT)
Received: (qmail 30914 invoked from network); 26 Oct 2011 16:16:17 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Oct 2011 16:16:14 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 26 Oct 2011 09:15:57 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Dan Taflin <dan.taflin@gettyimages.com>, OAuth WG <oauth@ietf.org>
Date: Wed, 26 Oct 2011 09:15:50 -0700
Thread-Topic: [OAUTH-WG] Rechartering
Thread-Index: AQHMj80/lXiDycBFuE2v7P/5IVRfpJWNqh8QgAErLjA=
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com>
In-Reply-To: <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Rechartering
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 26 Oct 2011 16:16:19 -0000

Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Dan Taflin
> Sent: Tuesday, October 25, 2011 3:37 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
> 
> I would like to second Torsten's pitch for the ability to return multiple access
> tokens with a single authorization process. The use case for my company is to
> segment operations into two main categories: protected and confidential. (A
> possible third category, public, would not require any authorization at all).
> Protected operations would be user-specific operations that don't involve
> the passing of any sensitive information, such as image search results tagged
> with information about whether each image is available for download by that
> user. Confidential operations would involve passing user data, like user
> registration or e-commerce. We would like to protect each category of
> operations with distinct tokens: a general-use token for protected
> operations, and a secure token for confidential operations.
> 
> We could use the scope parameter to specify either "protected" or
> "confidential". Currently the oauth spec allows a Refresh token to request a
> new token with reduced scope from the one originally issued, but there is no
> way to obtain a new token with a completely different scope without doing
> the full oauth dance a second time.
> 
> Dan
> 
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Thursday, October 20, 2011 3:57 PM
> To: Hannes Tschofenig
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
> 
> Hi all,
> 
> my prioritization is driven by the goal to make OAuth the authorization
> framework of choice for any internet standard protocol, such as WebDAV,
> IMAP, SMTP or SIP. So let me first explain what is missing from my point of
> view and explain some thoughts how to fill the gaps.
> 
> A standard protocol is defined in terms of resource types and messages by a
> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and
> used by different but deployment-independent clients.
> OAuth-based protocol specifications must also define scope values (e.g.
> read, write, send) and their relation to the resource types and messages. The
> different deployments expose the standard protocol on different resource
> server endpoints. In my opinion, it is fundamental
> to clearly distinguish scope values (standardized, static) and
> resource server addresses (deployment specific) and to manage their
> relationships. The current scope definition is much to weak and insufficient.
> Probably, the UMA concepts of hosts, resources sets, and corresponding
> scopes could be adopted for that purpose.
> 
> OAuth today requires clients to register with the service provider before
> they are deployed. Would you really expect IMAP clients, e.g.
> Thunderbird, to register with any a-Mail services upfront? So clients should
> be given a way to register dynamically to the authorization servers. This
> should also allow us to cover "client instance" aspects.
> It is interesting to note, that such a mechanism would allow us to get rid of
> secret-less clients and the one-time usage requirement for authorization
> codes.
> 
> We also assume the client to know the URLs of the resource server and the
> corresponding authorization server and to use HTTPS server authentication
> to verify the resource server's authenticity. This is impossible in the standard
> scenario. Clients must be able to discover the authorization server a
> particular resource server relies on at runtime. The discovery mechanism
> could be specified by the OAuth WG, but could also be part of an application
> protocols specification. But we MUST find another way to prevent token
> phishing by counterfeit resource servers.
> 
> As one approach, the client could pass the (previously HTTPS
> validated) resource server's URL with the authorization request. The
> authorization server should then refuse such requests for any unknown
> (counterfeit) resource servers. Such an additional parameter could also serve
> as namespace for scope values and enable service providers to run multiple
> instances of the same service within a single deployment.
> 
> If the additional data enlarges the request payload to much, we could
> consider to adopt the "request by reference" proposal.
> 
> Let's now assume, OAuth is successful in the world of standard protocols and
> we will see plenty of deployments with a bunch of different OAuth
> protected resource servers. Shall this servers all be accessible with a single
> token? In my opinion, this would cause security, privacy and/or
> scalability/performance problems. To give just the most obvious example,
> the target audience of such a token cannot be restricted enough, which may
> allow a resource server (or an attacker in control of it) to abuse the token on
> other servers. But the current design of the code grant type forces
> deployments to use the same token for all services. What is needed from my
> point of view is a way to request and issue multiple server-specific access
> tokens with a single authorization process.
> 
> I've been advocating this topic for a long time now and I'm still convinced this
> is required to really complete the core design. We at Deutsche Telekom
> needed and implemented this function on top of the existing core. In my
> opinion, a core enhancement would be easier to handle and more powerful.
> If others support this topic, I would be willed to submit an I-D describing a
> possible solution.
> 
> If we take standards really seriously, then service providers should be given
> the opportunity to implement their service by utilizing standard server
> implementations. This creates the challenge to find a standardized protocol
> between authorization server and resource server to exchange authorization
> data. Depending on the token design (self-contained vs. handle) this could
> be solved by either standardizing a token format (JWT) or an authorization
> API.
> 
> Based on the rationale given above, my list is as follows (topics w/o I-D are
> marked with *):
> 
> - Revocation (low hanging fruit since I-D is ready and implemented in some
> places)
> - Resource server notion*
> - Multiple access tokens*
> - Dynamic client registration
>   1) Dynamic Client Registration Protocol
>   4) Client Instance Extension
> - Discovery
>   (10) Simple Web Discovery, probably other specs as well
> - (6) JSON Web Token
> - (7) JSON Web Token (JWT) Bearer Profile
> - 8) User Experience Extension
> - Device flow
> - 9) Request by Reference
>   (depending resource server notion and multiple access tokens)
> 
> regards,
> Torsten.
> Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>et>:
> 
> > Hi all,
> >
> > in preparation of the upcoming IETF meeting Barry and I would like to
> > start a re-chartering discussion.  We both are currently attending the
> > Internet Identity Workshop and so we had the chance to solicit input
> > from the participants. This should serve as a discussion starter.
> >
> > Potential future OAuth charter items (in random order):
> >
> > ----------------
> >
> > 1) Dynamic Client Registration Protocol
> >
> > Available document:
> > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/
> >
> > 2) Token Revocation
> >
> > Available document:
> > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
> >
> > 3) UMA
> >
> > Available document:
> > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
> >
> > 4) Client Instance Extension
> >
> > Available document:
> > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt
> >
> > 5) XML Encoding
> >
> > Available document:
> > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt
> >
> > 6) JSON Web Token
> >
> > Available document:
> > http://tools.ietf.org/html/draft-jones-json-web-token-05
> >
> > 7) JSON Web Token (JWT) Bearer Profile
> >
> > Available document:
> > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00
> >
> > 8) User Experience Extension
> >
> > Available document:
> > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
> >
> > 9) Request by Reference
> >
> > Available document:
> > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00
> >
> > 10) Simple Web Discovery
> >
> > Available document:
> > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
> >
> > ----------------
> >
> > We have the following questions:
> >
> > a) Are you interested in any of the above-listed items? (as a
> > reviewer, co-author, implementer, or someone who would like to
> > deploy). It is also useful to know if you think that we shouldn't work
> > on a specific item.
> >
> > b) Are there other items you would like to see the group working on?
> >
> > Note: In case your document is expired please re-submit it.
> >
> > Ciao
> > Hannes & Barry
> >
> > _______________________________________________
> > 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