Re: [OAUTH-WG] Rechartering

[Igor Faynberg <[e-mail]>]

Actually, I think we need to document the use case.

Igor

On 10/25/2011 7:08 PM, Dave Rochwerger wrote:
> Is separating this out into 2 different tokens, really the best way to 
> solve your use case?
>
> It sounds to me that you simply want to track/log the two types of 
> accesses differently, which can be done entirely outside of the oauth2 
> process.
> Just bucket your operations into two piles internally and track 
> appropriately (which you would have to do anyway with scopes).
>
> Scopes are the specific access that the end user grants to a 3rd party 
> to access their protected resources.
>
> When an application, to use your example, asks for the scope 
> "protected confidential", they are providing those two levels of 
> access to the 3rd party application. If the user says "allow", then 
> that application has all the access that those two scopes provides.
>
> Rather than getting applications to then further choose between two 
> tokens to simply delineate two sets of operations seems like the wrong 
> place to be doing this.
> i.e., why does the 3rd party application have to choose which token to 
> use for each set of operations? - the user has already granted both. 
> The resource server can do whatever tracking/logging it wants based on 
> the actual operations requested - using the single token in this case.
>
> Regards,
> Dave
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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:[e-mail]
>     <mailto:[e-mail]>]
>     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 <[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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth