That's a whole different issue as this is about talking to a single server retuning two tokens with different scopes.
EHL ________________________________________ From: Dick Hardt [dick.ha...@gmail.com] Sent: Saturday, October 29, 2011 12:07 AM To: Eran Hammer-Lahav Cc: Dan Taflin; OAuth WG Subject: Re: [OAUTH-WG] Rechartering What if the access tokens come from different authoritative servers? On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
