I'll let you know when I see the I-D :-) EHL
> -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Friday, June 11, 2010 12:51 PM > To: Eran Hammer-Lahav > Cc: David Recordon; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single > authorization flow > > Hi, > > thanks for your advice. I described the new parameter in my proposal. > What additional text/information would you expect in an I-D? > > regards, > Torsten. > > Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav: > > I strongly believe that it should be first presented as an I-D. This is > > true in > general for most proposed changes of this size. It is hard to tell how big of > an > impact a change like this will have without some actual text. Once proposed, > the WG can decide if this is of interest as a WG item. If it is, we discuss > the > technical details. Then, we can have a chat about editorial work and how to > best fit it within the OAuth specifications framework. > > > > Hope this helps. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of David Recordon > >> Sent: Thursday, June 10, 2010 8:54 AM > >> To: Torsten Lodderstedt > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a > >> single authorization flow > >> > >> I strongly believe that it should be an extension. Even optional > >> response parameters increase the complexity for client developers and > >> this in particular affects the data model used to store access tokens. > >> > >> --David > >> > >> > >> On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt > >> <tors...@lodderstedt.net> wrote: > >> > >>> no one in the WG having an opinion on this topic? > >>> > >>> Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: > >>> > >>>> Hi all, > >>>> > >>>> I would like to see support in OAuth2 for the authorization of > >>>> arbitrary scopes in a single authorization flow for all kinds of > >>>> deployments. In some deployments this may require to issue multiple > >>>> > >> access tokens at once. > >> > >>>> Therefore, I would like to propose the following addition to > >>>> section 2.3.2.1. (Access Token Response): > >>>> > >>>> Add an optional parameter "additional_access_tokens". > >>>> > >>>> additional_access_tokens > >>>> OPTIONAL. Array of access tokens issued by the authorization > >>>> server along with respective expiration and scope. > >>>> Used > >>>> if the authorization server decides to issue > >>>> more than > >>>> one access token. The scopes of the different > >>>> tokens may > >>>> not overlap. > >>>> > >>>> Example: > >>>> HTTP/1.1 200 OK > >>>> Content-Type: application/json > >>>> Cache-Control: no-store > >>>> > >>>> { > >>>> "access_token":"SlAV32hkKG", > >>>> "expires_in":3600, > >>>> "refresh_token":"8xLOxBtZp8", > >>>> scope:"https://imap.example.com";, > >>>> additional_access_tokens:[ > >>>> { > >>>> "access_token":"SlAV32hkKG2", > >>>> "expires_in":3600, > >>>> scope:"https://sip.example.com"; > >>>> }, > >>>> { > >>>> "access_token":"SlAV32hkKG3", > >>>> "expires_in":3600, > >>>> scope:"https://contacts.example.com/read"; > >>>> }, > >>>> { > >>>> "access_token":"SlAV32hkKG4", > >>>> "expires_in":3600, > >>>> scope:"https://webdav.example.com/read"; > >>>> } > >>>> ] > >>>> } > >>>> > >>>> --- Some motivation --- > >>>> > >>>> I think we will see more and more clients integrating different > >>>> end-user services (like mashups). Based on the current draft, some > >>>> OAuth authorization servers may not be able to support such clients > >>>> with an acceptable user experiences. > >>>> > >>>> Suppose a communication client integrating the following services: > >>>> - e-Mail via IMAP > >>>> - Voice over IP using the SIP protocol > >>>> - Contacts via SyncML over HTTP > >>>> - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV > >>>> > >>>> For a particular end-user, the client may discover that all of the > >>>> end-user's services rely on the same OAuth2-based authorization > >>>> server because they are provided by the same organization (e.g. an > >>>> isp or > >>>> > >> a telco). > >> > >>>> The services are distinguished at the authorization server by > >>>> different scopes (probably including permissions as well), e.g. : > >>>> > >>>> imap - https://imap.example.com > >>>> sip - https://sip.example.com > >>>> contacts - https://contacts.example.com/read webstorage - > >>>> https://contacts.example.com/read > >>>> > >>>> Some providers may want to issue different service-specific tokens > >>>> in such a setup (Deutsche Telekom does it already), for the > >>>> following > >>>> > >> reasons: > >> > >>>> 1) Security > >>>> > >>>> a) minimize impact of token abuse - tokens may leak in many ways, > e.g. > >>>> through log files, proxies or HTTP referer. If a provider just uses > >>>> a single token for all services, the impact of token leakage is > >>>> much higher. For example, if a token gets exposed by the _contacts_ > >>>> service via HTTP referer, an adversary may place long-distance > >>>> calls using that token on the _VoIP_ service at the expense of the > >>>> end-user. This threat holds for all kinds of tokens (handles and > >>>> self- > >>>> > >> contained tokens). > >> > >>>> b) use a shared secret between authz server and a single service > >>>> only - a major critism from the operational security perspective to > >>>> OAuth 1.0a was the need to spread client secrets to resource servers. > >>>> Using the same shared secret to sign/encrypt tokens for different > >>>> services is a comparable problem. This aspect is relevant for self- > >>>> > >> contained tokens, only. > >> > >>>> 2) Privacy - the provider wants to restrict access of services to > >>>> personal data to the data a particular service is allowed and > >>>> authorized to see. This is good style (IMHO), it might also be > >>>> required by law (e.g. German Federal Data Protection Act). This > >>>> aspect is relevant for self-contained tokens, only. > >>>> > >>>> 3) Bandwith efficiency - putting only the data required by the > >>>> services into the token saves bandwith. This aspect is relevant for > >>>> self-contained tokens, only. > >>>> > >>>> In my opinion, most of these aspects are just a consequence of the > >>>> decoupling of authorization server and resource server(s) in OAuth2. > >>>> If a single authorization server is responsible for several > >>>> resource servers, it has to ensure privacy protection and > >>>> prevention of token abuse for all of its services. This should also > >>>> include some separation between services, no matter if one uses > >>>> self-contained tokens > >>>> > >> or handles. > >> > >>>> Without the change I proposed, the authorization server in the > >>>> example scenario would need to force the client to perform _four_ > >>>> subsequent authorization flows in order to obtain all required > >>>> tokens. Moreover, the client would need to manage four refresh > tokens. > >>>> > >>>> I would kindly ask you to support my proposal. In my opinion, it > >>>> significantly improves the applicability of OAuth2 while the change > >>>> to the current draft is minimal. Moreover, deployments w/o the need > >>>> to issue multiple tokens are not affected at all. > >>>> > >>>> Any thoughts? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> _______________________________________________ > >>>> 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
