Re: [OAUTH-WG] Rechartering
Dan Taflin <dan.taflin@gettyimages.com> Tue, 25 October 2011 23:21 UTC
Return-Path: <dan.taflin@gettyimages.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 EADBD11E8082 for <oauth@ietfa.amsl.com>; Tue, 25 Oct 2011 16:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Xw6QYgRWkpwW for <oauth@ietfa.amsl.com>; Tue, 25 Oct 2011 16:21:04 -0700 (PDT)
Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by ietfa.amsl.com (Postfix) with ESMTP id F0AE01F0C4B for <oauth@ietf.org>; Tue, 25 Oct 2011 16:21:03 -0700 (PDT)
X-Env-Sender: dan.taflin@gettyimages.com
X-Msg-Ref: server-11.tower-143.messagelabs.com!1319584866!92894834!1
X-Originating-IP: [216.169.250.56]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32325 invoked from network); 25 Oct 2011 23:21:06 -0000
Received: from london.webmail.gettyimages.com (HELO SEAPXCH10CAHT02.amer.gettywan.com) (216.169.250.56) by server-11.tower-143.messagelabs.com with AES128-SHA encrypted SMTP; 25 Oct 2011 23:21:06 -0000
Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT02.amer.gettywan.com ([::1]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 16:21:02 -0700
From: Dan Taflin <dan.taflin@gettyimages.com>
To: Dave Rochwerger <daver@quizlet.com>
Thread-Topic: [OAUTH-WG] Rechartering
Thread-Index: AQHMj80/lXiDycBFuE2v7P/5IVRfpJWNqh8QgACBmAD//4tusA==
Date: Tue, 25 Oct 2011 23:21:01 +0000
Message-ID: <429493818451304B84EC9A0797B5D8582385DD@SEAPXCH10MBX01.amer.gettywan.com>
References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <CAGyXixx4KG9an0n6utCK_3hc35tEJ+1McGJs1S1DwVGoXLjw7Q@mail.gmail.com>
In-Reply-To: <CAGyXixx4KG9an0n6utCK_3hc35tEJ+1McGJs1S1DwVGoXLjw7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.102.80]
Content-Type: multipart/alternative; boundary="_000_429493818451304B84EC9A0797B5D8582385DDSEAPXCH10MBX01ame_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
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: Tue, 25 Oct 2011 23:21:10 -0000
You're right, if tracking was all we needed then a single token would suffice. The reason for two tokens has more to do with the fact that we'd like to allow "protected" operations to be called over plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that token gave him access to was relatively benign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan for the token). In contrast, "confidential" operations would only be callable over https. By requiring a different token for them (and not allowing that token to be used for unprotected operations) we prevent it from being intercepted. This design intentionally mimics the way secure and non-secure http cookies work. Oauth today basically requires https for all bearer token implementations. I would like to see this relaxed somewhat. Dan From: Dave Rochwerger [mailto:daver@quizlet.com] Sent: Tuesday, October 25, 2011 4:08 PM To: Dan Taflin Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Is separating this out into 2 different tokens, really the best way to solve your use case? It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process. Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes). Scopes are the specific access that the end user grants to a 3rd party to access their protected resources. When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides. Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the wrong place to be doing this. i.e., why does the 3rd party application have to choose which token to use for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case. Regards, Dave On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gettyimages.com<mailto:dan.taflin@gettyimages.com>> wrote: 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<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<mailto:hannes.tschofenig@gmx.net>>: > 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<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Rechartering Thomas Hardjono
- [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering David Recordon
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Christian Scholz
- Re: [OAUTH-WG] Rechartering Brian Campbell
- Re: [OAUTH-WG] Rechartering Igor Faynberg
- Re: [OAUTH-WG] Rechartering Justin Richer
- Re: [OAUTH-WG] Rechartering Mark Mcgloin
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Eve Maler
- Re: [OAUTH-WG] Rechartering Eliot Lear
- Re: [OAUTH-WG] Rechartering Mark Mcgloin
- Re: [OAUTH-WG] Rechartering Anthony Nadalin
- Re: [OAUTH-WG] Rechartering Mike Jones
- Re: [OAUTH-WG] Rechartering Eve Maler
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Barry Leiba
- Re: [OAUTH-WG] Rechartering Richer, Justin P.
- Re: [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Mike Jones
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Hannes Tschofenig
- Re: [OAUTH-WG] Rechartering Igor Faynberg
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Nat Sakimura
- Re: [OAUTH-WG] Rechartering Dan Taflin
- Re: [OAUTH-WG] Rechartering Dave Rochwerger
- Re: [OAUTH-WG] Rechartering Dan Taflin
- Re: [OAUTH-WG] Rechartering Dave Rochwerger
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering Igor Faynberg
- Re: [OAUTH-WG] Rechartering Nat Sakimura
- Re: [OAUTH-WG] Rechartering JSON based request. John Bradley
- Re: [OAUTH-WG] Rechartering John Bradley
- Re: [OAUTH-WG] Rechartering JSON based request. Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering JSON based request. Igor Faynberg
- Re: [OAUTH-WG] Rechartering JSON based request. Igor Faynberg
- Re: [OAUTH-WG] Rechartering JSON based request. John Bradley
- Re: [OAUTH-WG] Rechartering JSON based request. torsten
- Re: [OAUTH-WG] Rechartering JSON based request. Phil Hunt
- Re: [OAUTH-WG] Rechartering JSON based request. Mike Jones
- Re: [OAUTH-WG] Rechartering JSON based request. Phil Hunt
- Re: [OAUTH-WG] Rechartering Multi Token Ressponse. John Bradley
- Re: [OAUTH-WG] Rechartering JSON based request. George Fletcher
- Re: [OAUTH-WG] Rechartering JSON based request. Nat Sakimura
- Re: [OAUTH-WG] Rechartering Dick Hardt
- Re: [OAUTH-WG] Rechartering William Mills
- Re: [OAUTH-WG] Rechartering John Bradley
- Re: [OAUTH-WG] Rechartering Eran Hammer-Lahav
- Re: [OAUTH-WG] Rechartering Anthony Nadalin
- Re: [OAUTH-WG] Rechartering JSON based request. Torsten Lodderstedt
- Re: [OAUTH-WG] Rechartering JSON based request. John Bradley
- Re: [OAUTH-WG] Rechartering Dick Hardt