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: [email protected] [mailto:[email protected]] On Behalf > Of David Recordon > Sent: Thursday, June 10, 2010 8:54 AM > To: Torsten Lodderstedt > Cc: OAuth WG ([email protected]) > 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 > <[email protected]> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
