Re: [OAUTH-WG] Rechartering JSON based request.

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 02 November 2011 19:32 UTC

Return-Path: <torsten@lodderstedt.net>
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 AD9401F0C95 for <oauth@ietfa.amsl.com>; Wed, 2 Nov 2011 12:32:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LflKb7d6XaTM for <oauth@ietfa.amsl.com>; Wed, 2 Nov 2011 12:32:11 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 076871F0C8C for <oauth@ietf.org>; Wed, 2 Nov 2011 12:32:10 -0700 (PDT)
Received: from [87.142.252.185] (helo=[192.168.71.26]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1RLgXg-0000J9-LY; Wed, 02 Nov 2011 20:32:08 +0100
Message-ID: <4EB19AB8.6020703@lodderstedt.net>
Date: Wed, 02 Nov 2011 20:32:08 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: George Fletcher <gffletch@aol.com>
References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <CABzCy2BLp=Hh3HdyDdOGF4nZ6TMLRdiuRMzWDPvB3T2Y_fcfNA@mail.gmail.com> <4EA84E97.3020708@lodderstedt.net> <D3FB5359-DDDE-4EF7-BD69-053F5647FE4E@ve7jtb.com> <4EA8EA99.4010203@lodderstedt.net> <A8E6FEDE-8A52-47A7-9C3B-33E0594D5608@ve7jtb.com> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> <4EA9BE04.9060607@aol.com>
In-Reply-To: <4EA9BE04.9060607@aol.com>
Content-Type: multipart/alternative; boundary="------------010905060204010700040805"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rechartering JSON based request.
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, 02 Nov 2011 19:32:13 -0000

Hi,

standard OAuth does not sign request parameters. Does this mean OAuth 
itself is not secure enough? Or is there a new threat angle against 
those parameters in the contect of Connect?

regards,
Torsten.

Am 27.10.2011 22:24, schrieb George Fletcher:
> The main reason to include the OAuth parameters in the request is to 
> ensure that the request object was not modified in transit since the 
> JSON request object can be signed. Agreed that it would be simpler if 
> OAuth adopted the JSON request style.
>
> Thanks,
> George
>
> On 10/27/11 1:33 PM, torsten@lodderstedt.net wrote:
>> Hi John,
>>
>> why do you need to include the OAuth request parameters into the JSON 
>> document? I would expect OpenId Connect to extend OAuth 
>> none-intrusively. This would mean to use the JSON document for OpenId 
>> connect specific parameters only. Alternatively, the JSON request 
>> style could be adopted as part of OAuth. Then, the URI request 
>> parameters could be omitted.
>>
>> regards,
>> Torsten.
>>
>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>>
>> ------------------------------------------------------------------------
>> *From: * John Bradley <ve7jtb@ve7jtb.com>
>> *Date: *Thu, 27 Oct 2011 13:52:31 -0300
>> *To: *Torsten Lodderstedt<torsten@lodderstedt.net>
>> *Cc: *Nat Sakimura<sakimura@gmail.com>om>; OAuth WG<oauth@ietf.org>
>> *Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
>>
>> Hopefully to make it more compatible with existing OAuth 2 libraries. 
>>    At least leave open the possibility of dealing with it at a higher 
>> level.
>>
>> The argument has been made that you probably need to modify the 
>> library anyway to check that the duplicate parameters are a match.
>>
>> If there is consensus that the parameters should only be in the JSON 
>> then we would happily not duplicate them.
>>
>> It is mostly a case of trying to fit in to the existing OAuth work 
>> and libraries.
>>
>> John B.
>>
>> On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
>>
>>> why is it neccessary to duplicate the OAuth request parameters?
>>>
>>> Am 27.10.2011 00:31, schrieb John Bradley:
>>>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>>>>
>>>> It is essentially  a standardization of the method we are using in 
>>>> openID Connect to make signed requests to the Authorization server.
>>>>
>>>> We do have the issue that parameters in the signed/encrypted 
>>>> request necessarily duplicate the query parameters to keep it a 
>>>> valid OAuth request plus an extension.
>>>>
>>>> Even if it doesn't wind up as a OAuth WG item it is probably worth 
>>>> people looking at it before the final openID spec is voted on.
>>>>
>>>> Regards
>>>> John B.
>>>>
>>>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
>>>>
>>>>> Hi Nat,
>>>>>
>>>>> I think your proposal would be a useful OAuth enhancement. A 
>>>>> JSON-based request format would allow for more complex requests 
>>>>> (e.g. carrying resource server URLs and corresponding scope values 
>>>>> ;-)).
>>>>>
>>>>> Please note: I also think the way this mechanism is introduced and 
>>>>> used in the current OpenID connect spec requires OpenID connect 
>>>>> clients and servers to handle OAuth request parameters differently 
>>>>> than for standard OAuth requests. Introducing the JSON based claim 
>>>>> request capability to OAuth would be a way to cope with this.
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>
>>>>> Am 22.10.2011 16:00, schrieb Nat Sakimura:
>>>>>> Hi.
>>>>>>
>>>>>> Just a clarification:
>>>>>>
>>>>>> Although my expired draft is 'request by reference', what was 
>>>>>> proposed through it at the iiw really is a generalized JSON based 
>>>>>> claim request capability. It could be passed by value as JSON or 
>>>>>> could be passed by reference. The later is an optimization for 
>>>>>> bandwidth constrained network as well as strengthening security 
>>>>>> in some ways. This capability already exists in OpenID Connect 
>>>>>> but it is actually an underpinning transport, so it probably 
>>>>>> should belong to OAuth instead. This was the primary reason for 
>>>>>> the proposal.
>>>>>>
>>>>>> Nat
>>>>>>
>>>>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
>>>>>> <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>>>>>>
>>>>>>     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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Nat Sakimura (=nat)
>>>>>> Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/
>>>>>> @_nat_en
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>