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

Nat Sakimura <sakimura@gmail.com> Fri, 28 October 2011 00:28 UTC

Return-Path: <sakimura@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 2EB0D11E8099 for <oauth@ietfa.amsl.com>; Thu, 27 Oct 2011 17:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.182
X-Spam-Level:
X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kR6q2SbGaroZ for <oauth@ietfa.amsl.com>; Thu, 27 Oct 2011 17:28:16 -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 5807311E808F for <oauth@ietf.org>; Thu, 27 Oct 2011 17:28:15 -0700 (PDT)
Received: by faas12 with SMTP id s12so3650793faa.31 for <oauth@ietf.org>; Thu, 27 Oct 2011 17:28:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3hKdfbHK39CG6IabwMuiBujrFYLGO3Z1NqAvNmzJW6I=; b=v6Mu97W0kjkl7JvKRvwz6HW7XYpfirKt4eE2WtCgbVFyqUGU8L7wY019eS654yHGSG 2SltKSXezeysIPtrOf5sPn7OCLAIkDPGstMhagZGd2nwebqg/kHwHLK41PkPPB1Z1P/s BL9FuQcvrEf5e0IbU/ekQnPbxoviR947ik050=
MIME-Version: 1.0
Received: by 10.223.39.20 with SMTP id d20mr1770219fae.37.1319761693218; Thu, 27 Oct 2011 17:28:13 -0700 (PDT)
Received: by 10.152.37.201 with HTTP; Thu, 27 Oct 2011 17:28:13 -0700 (PDT)
In-Reply-To: <4EA9BE04.9060607@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>
Date: Fri, 28 Oct 2011 09:28:13 +0900
Message-ID: <CABzCy2CZm0juRq6-itrAoGpXgzQwtkM=1KtK5GrGZXjs9ez=ug@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=00151747914ee9969e04b050f646
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: Fri, 28 Oct 2011 00:28:18 -0000

Thanks George.

Just to clarify the intent of this I-D : this I-D proposes the JSON request
style to be adopted as part of OAuth so that the URI request parameters
could be omitted.

=nat

On Fri, Oct 28, 2011 at 5:24 AM, George Fletcher <gffletch@aol.com> wrote:

>  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> <ve7jtb@ve7jtb.com>
> *Date: *Thu, 27 Oct 2011 13:52:31 -0300
> *To: *Torsten Lodderstedt<torsten@lodderstedt.net><torsten@lodderstedt.net>
> *Cc: *Nat Sakimura<sakimura@gmail.com> <sakimura@gmail.com>om>; OAuth WG
> <oauth@ietf.org> <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> 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>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
>>
>
>
>
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>   _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en