Some may argue that MAC tokens are not necessarily more secure:) Eran's solution may well be sufficient for MAC (i still think downs scoping is necessary if symmetric keys are used), however there are people using BEARER who encode information into signed tokens.
Those people also use the implicit flow. There is no option at the moment other than returning multiple tokens. John B. On 2011-10-29, at 12:04 PM, William Mills wrote: > There's a problem here, which I think Eran's proposal of differentiating with > scopes solves that should be made explicit, to whit, how does the client know > which token to use in a specific context. We have two options: one is to > specify different scopes, and the other is to use different token types. > > In the use case presented where it's different security levels would just > choose to go with the more secure MAC token in all cases, but it's probably > worth noting how to do this. > > -bill > From: Dick Hardt <dick.ha...@gmail.com> > To: Eran Hammer-Lahav <e...@hueniverse.com> > Cc: OAuth WG <oauth@ietf.org>; Dan Taflin <dan.taf...@gettyimages.com> > Sent: Saturday, October 29, 2011 12:07 AM > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
