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

[Igor Faynberg <[e-mail]>]

Many thanks for pointing this!  It is *absolutely* (not "probably") 
worth studying.

Igor

On 10/26/2011 6:31 PM, John Bradley wrote:
> 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