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

[Torsten Lodderstedt <[e-mail]>]

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, [e-mail] 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 <[e-mail]>
>> *Date: *Thu, 27 Oct 2011 13:52:31 -0300
>> *To: *Torsten Lodderstedt<[e-mail]>
>> *Cc: *Nat Sakimura<[e-mail]>; OAuth WG<[e-mail]>
>> *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 
>>>>>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>>>>>>     <mailto:[e-mail]>>:
>>>>>>
>>>>>>
>>>>>>         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
>>>>>>         [e-mail] <mailto:[e-mail]>
>>>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OAuth mailing list
>>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Nat Sakimura (=nat)
>>>>>> Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/
>>>>>> @_nat_en
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>