Re: [OAUTH-WG] Rechartering

Dick Hardt <dick.hardt@gmail.com> Sat, 29 October 2011 07:07 UTC

Return-Path: <dick.hardt@gmail.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 57E7411E808B for <oauth@ietfa.amsl.com>; Sat, 29 Oct 2011 00:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 YUy4PlBT7r7r for <oauth@ietfa.amsl.com>; Sat, 29 Oct 2011 00:07:57 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67C6B11E807F for <oauth@ietf.org>; Sat, 29 Oct 2011 00:07:57 -0700 (PDT)
Received: by faas12 with SMTP id s12so4893371faa.31 for <oauth@ietf.org>; Sat, 29 Oct 2011 00:07:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=w/KcB49jK30n35df2e8dhHNTUxt3tTGW5JLPQlMO40U=; b=ejEmpf7UdkLBRECR28nIhM158OqsGFRQfRZClVCviy/bYn7SCSKma4G7UqbvX5iD+s ESbRp9ybV/IaD//UeMZ/fBgHj/t4LpX7s0p7L2x28plFhQJKoVzeKWygZW2mXmX9g/9n 5ieozkONVsCt1RGWBkjQmz2+zRrlOOZkUBjzQ=
Received: by 10.223.77.71 with SMTP id f7mr11814673fak.33.1319872072014; Sat, 29 Oct 2011 00:07:52 -0700 (PDT)
Received: from [192.168.2.121] ([62.87.186.202]) by mx.google.com with ESMTPS id a21sm22254897fao.18.2011.10.29.00.07.47 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 00:07:50 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sat, 29 Oct 2011 00:07:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com>
References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: OAuth WG <oauth@ietf.org>, Dan Taflin <dan.taflin@gettyimages.com>
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: Sat, 29 Oct 2011 07:07:59 -0000

What if the access tokens come from different authoritative servers?

On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote:

> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth