Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Dan Taflin > Sent: Tuesday, October 25, 2011 3:37 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > 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:tors...@lodderstedt.net] > 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 <hannes.tschofe...@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 > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > 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
