Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 3 Jun 2010 20:10:53 +0200

Hi!
I'm curious why this is impossible. If access tokens are arbitrary
handles which are generated by the authorization server and
distributed to all resources, it doesn't make much difference whether
one or multiple are generated and in this case it would be better to
keep the load on the server rather complicating things for clients.
In the scenario (as you have mentioned) where access tokens are
self-contained and digitally signed, would it not be possible to
generate a "super token" which contains signatures from all resources?
I agree this token might be a bit lengthy, but is there any other
concern?!

Regards,
 Lukas

2010/5/25 Torsten Lodderstedt <[email-masked]>:
> As I said, every service in our setup needs another access token, with
> different content, signed and encrypted with another shared secret. It is
> technically impossible to create the super access token. Refresh tokens are
> just handles representing the user's authorization and are used by the authz
> server only. They therefore can represent any scope.

-- 
http://lukasrosenstock.net/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 03 Jun 2010 20:27:19 +0200

I probably exaggerated a bit. It's not impossible but it is complex and 
insecure for several reasons:

1) Such a super token would need to contain the union of all data and 
permissions needed by all requested target services.
2) Not all services may by authorized to see all data contained in such 
a super token (privacy!). So, you would need to built different 
service-specific (encrypted) compartments within the token.
3) There are target-service-specific characteristics of such a token, 
such as the audience and the signature. You would need to have such 
attributes per service. Using public-key cryptography would relieve this 
point but slow down processing.
4) You have to (somehow) prevent a target service from _abusing_ this 
token to access another service for which the super token is valid for. 
The only way I see is the usage of the client secret.

That's why I think, returning multiple tokens is much simpler.

regards,
Torsten.

Am 03.06.2010 20:10, schrieb Lukas Rosenstock:
> 2010/5/25 Torsten Lodderstedt<[email-masked]>:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 04 Jun 2010 09:27:08 +0200

BTW: the security threat I described in point 4) not only holds for 
self-contained tokens but also for (super) handles. I consider it 
especially dangerous if abusing a service causes costs for the end-user.

regards,
Torsten.

Am 03.06.2010 20:27, schrieb Torsten Lodderstedt:
> I probably exaggerated a bit. It's not impossible but it is complex 
> and insecure for several reasons:
>
> 2) Not all services may by authorized to see all data contained in 
> such a super token (privacy!). So, you would need to built different 
> attributes per service. Using public-key cryptography would relieve 
> this point but slow down processing.
> token to access another service for which the super token is valid 
> for. The only way I see is the usage of the client secret.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Fri, 4 Jun 2010 11:04:05 -0400

What if you had a supertoken that was only good for getting subtokens?
In other words, only the AS knows about the supertoken (a refresh token,
perhaps?), and it allows you to get sub-tokens using the refresh flow to
access each of the different services. Then you could grab as many
different tokens with individual scopes as you want. 

This could also be an application for the rescoping proposal, which I'm
liking more now. I've had some colleagues ask me about redelegation in
OAuth2, and I'm starting to think that the rescoping methods might be
the right answer there. I see Torsten's problem as something similar:
you get a token that's good for getting other tokens but not for
accessing protected resources (the refresh token). You then use this
token that has a "global" scope to request tokens with more directed
scopes, which can have all of the per-service signed characteristics in
the token itself that Torsten was talking about. 

Would that work?

 -- Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 04 Jun 2010 23:42:03 +0200

> different tokens with individual scopes as you want.

I've been thinking about your idea and came up with the following options.

1) authz-server token
  Let's assume the authorization server issues service-specific 
(ordinary) access tokens as long as it's possible. If the authorization 
encounters a scope which requires different access tokens, e.g. 
"imap,sip,contacts", it issues a special access token instead. Let's 
call it "authz-server" token. The scope of the access token issued is 
indicated by a scope return parameter.

      {
        "access_token":"SlAV32hkKG",
         "scope":["authz-server"]
        "expires_in":3600
      }

So clients detect the different outcome by evaluating the scope response 
parameter. Tokens with the special scope "authz-server" are used to 
acquire service-specific access tokens using the new request 
"issue_token" (using the assertion flow would also be an option). The 
desired target service is indicated by a scope parameter. I see 
different way how this request could work:

  a) input: orginal scope, output: cannot work for the same reasons the 
authz flow responded with a "authz-server" token
     Seems we just shifted the problem :-(

  b) input: orginal scope, output: multiple access tokens
     Why did'nt the authorization flow respond that way? Ok, we don't 
like arrays of tokens. But how can we circumvent that "problem"?

  c) input: single scope element in (e.g. "imap"), output: token for 
that scope element only
      This works, but the client needs to call that request for each and 
every string in the original scope. That may cause a lot of unnecessary 
network communication.

  d) input: single scope element in, output: token for that scope 
element and all other applicable scopes elements
      So the result would be the token with the maximum privileges out 
of the "authz-token" relative to the requested scope element.

      {
        "access_token":"SlAV32hkKG",
         "scope":["imap", "contacts"]
        "expires_in":3600
      }

Pro: no token array
Con: increases the number of requests a client has to exchange with the 
authorization server.

2) refresh token
Apparently, the authorization server could also return a refresh token 
instead of an acess token, if it encounters a multi-service scope. The 
refresh token request could than be used to actually issue access 
tokens. The request variants are the same as for option (1). Using 
refresh tokens that way causes a significant change in the refresh token 
semantics. Currently, they are (1) long-living, (2) optional for some 
flows and (3) not issued by other flows. With the new semantics, (1) all 
flows would need to (optionally) issue refresh tokens and (2) all kinds 
of duration would be possible (from short- to long-living).

I'm still convinced that just returning multiple access token from the 
authz flow (and the refresh token request) would be the simplest 
solution. Since a request token is really powerful in a multi-service 
situation, support for scope downgrading by the refresh token request 
would be a reasonable complement.

------------------------------------------------------------------------------------------------------------

I think it's crucial to agree on the following: authorization of access 
to different services, which propably require different access tokens, 
within a single authorization flow is a relevant use case for OAuth2.

In my opinion, this is 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.

If we agree on the relevance of that use case, we will find a solution. 
I'm open for feedback and ideas.

Any thoughts?

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 09 Jun 2010 12:19:08 +0200

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 10 Jun 2010 17:46:12 +0200

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.
>
> 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.
>
>  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).
>
> the same shared secret to sign/encrypt tokens for different services 
> is a comparable problem. This aspect is relevant for self-contained 
> tokens, only.
>
> 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 
> decoupling of authorization server and resource server(s) in OAuth2. 
> If a single authorization server is responsible for several resource 
> abuse for all of its services. This should also include some 
> separation between services, no matter if one uses self-contained 
> tokens or handles.
>

---

From: David Recordon <[email-masked]>
Date: Thu, 10 Jun 2010 08:54:13 -0700

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-masked]> wrote:
>> scopes in a single authorization flow for all kinds of deployments. In some
>> deployments this may require to issue multiple access tokens at once.
>>
>>                    server along with respective expiration and scope. Used
>>                    one access token. The scopes of the different tokens
>> may
>>                    not overlap.
>>
>> Example:
>>     HTTP/1.1 200 OK
>> 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. :
>>
>> 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
>>
>> 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.
>>
>> into the token saves bandwith. This aspect is relevant for self-contained
>> tokens, only.
>>
>> 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.
>>
>> authorization flows in order to obtain all required tokens. Moreover, the
>> client would need to manage four refresh tokens.
>>
>> 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.
>>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 10 Jun 2010 13:00:07 -0400

I thought I had already written this, but I guess the e-mail never went 
anywhere... 

I do have a strong opinion on Torsten's proposal, and it is POSITIVE.

A nit pick: I would replace "Array" with "List," to read "A list of 
access tokens issued..."

Igor

Torsten Lodderstedt wrote:
>> 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. :
>>
>> 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 
>> required by law (e.g. German Federal Data Protection Act). This 
>> aspect is relevant for self-contained tokens, only.
>>
>> 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.
>>
>> 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.
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Jun 2010 16:02:50 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of David Recordon
> Sent: Thursday, June 10, 2010 8:54 AM
> To: Torsten Lodderstedt
> Cc: OAuth WG ([email-masked])
> 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
> 
> 
> >> 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
> >> contacts - https://contacts.example.com/read webstorage -
> >> https://contacts.example.com/read
> >>
> >> higher. For example, if a token gets exposed by the _contacts_
> >> end-user. This threat holds for all kinds of tokens (handles and self-
> contained tokens).
> >>
> >> services is a comparable problem. This aspect is relevant for self-
> contained tokens, only.
> >>
> >> separation between services, no matter if one uses self-contained tokens
> or handles.
> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 11 Jun 2010 21:50:31 +0200

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:
>>>> such a setup (Deutsche Telekom does it already), for the following
>>>>          
>> reasons:
>>      
>>>> 1) Security
>>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 13:12:35 -0700

I'll let you know when I see the I-D :-)

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Friday, June 11, 2010 12:51 PM
> To: Eran Hammer-Lahav
> Cc: David Recordon; OAuth WG ([email-masked])
> > 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
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of David Recordon
> >> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a
> >> single authorization flow
> >>
> >>>> Therefore, I would like to propose the following addition to
> >>>> section 2.3.2.1. (Access Token Response):
> >>>>
> >>>> isp or
> >>>> 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
> >>>>
> 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
> >>>> service via HTTP referer, an adversary may place long-distance
> >>>> calls using that token on the _VoIP_ service at the expense of the
> >>>> self-
> >>>> 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.
> >>

---

From: Breno <[email-masked]>
Date: Wed, 16 Jun 2010 08:17:19 -0700

Alternative proposal. Create a new call for 'dropping privileges' where a
client can present a single refresh token and scopes and obtain a new
refresh token/access token with defined scopes provided that these scopes
were already granted to the original token.

The advantage of a separate call is that it has less impact in
implementations because it does not modify existing flows. It is also more
flexible. For instance it would allow a client too split its privileges into
tokens with overlapping scopes for arbitrary requirements around security
and functionality of delegating its privileges.

On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

> Sent: F...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Jun 2010 08:32:08 -0700

The refresh token represents what the resource owner authorized. The access token can be a subset of that. The current draft already supports asking for less scope than was granted. It doesn't support asking for a new refresh token with less scope.

EHL

From: Breno [mailto:[email-masked]]
Sent: Wednesday, June 16, 2010 8:17 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow

Alternative proposal. Create a new call for 'dropping privileges' where a client can present a single refresh token and scopes and obtain a new refresh token/access token with defined scopes provided that these scopes were already granted to the original token.

The advantage of a separate call is that it has less impact in implementations because it does not modify existing flows. It is also more flexible. For instance it would allow a client too split its privileges into tokens with overlapping scopes for arbitrary requirements around security and functionality of delegating its privileges.
On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" <[email-masked]<mailto:[email-masked]>> wrote:

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: F...

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Jun 2010 11:49:52 -0400

We're looking at using the rescope operation to support redelegation,
and in this we wouldn't want to give the second client a refresh token
of their own, just an access token that is good for a subset of scopes
attached to the original refresh/access combination that the user
authorized. I'm not seeing a use case for asking for a new refresh token
using an existing refresh token as auth, though. Could you elaborate
what this might be?

 -- Justin

On Wed, 2010-06-16 at 11:32 -0400, Eran Hammer-Lahav wrote:
> The refresh token represents what the resource owner authorized. The
> access token can be a subset of that. The current draft already
> supports asking for less scope than was granted. It doesn’t support
> asking for a new refresh token with less scope.
> 
>  
> 
> EHL
> 
>  
> 
> Alternative proposal. Create a new call for 'dropping privileges'
> where a client can present a single refresh token and scopes and
> obtain a new refresh token/access token with defined scopes provided
> that these scopes were already granted to the original token.
> 
> implementations because it does not modify existing flows. It is also
> more flexible. For instance it would allow a client too split its
> privileges into tokens with overlapping scopes for arbitrary
> requirements around security and functionality of delegating its
> privileges.
>

---

From: Breno <[email-masked]>
Date: Wed, 16 Jun 2010 09:25:07 -0700

> using an existing refresh token as auth, though. Could you elaborate

Looking at the beginning of this thread, there is a proposal to return
each scope as a separate token.

This is presumably a separation of trust issue that the client would
like to enforce.

>From a protocol perspective, it would be simpler to exchange the new
refresh token for one with fewer privileges instead of
requesting/receiving one token per scope.

>> asking for a new refresh token with less scope.

Well, what about just returning a refresh token with the access token
when the requested set of scopes for the access token is stricter?

Of course, in the user-agent flow there is no refresh token.

>>         > -----Original Message-----
>>         > From: Torsten Lodderstedt [mailto:[email-masked]]
>>         > Sent: F...
>>
>
>
>

-- 
Breno de Medeiros

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 17 Jun 2010 11:54:22 +1000

Breno,

> The advantage of a separate call is that it has less impact in implementations because it does not modify existing flows. It is also more flexible. For instance it would allow a client too split it…

This alternative (dropping privileges) could work for clients that know everything about a service: which scopes are necessary & sufficient for each call, and that ‘dropping privileges’ is supported. It requires lots of service-specific knowledge in the client, and/or some reasonably sophisticated discovery (which is so far undefined, untried, and not obvious how it should be done). A service that requires dropped privileges can only reject calls that use full tokens (and hope that hasn’t already compromised security), and hope that clients can then discover how to drop privileges and what to drop them to (efficiently & simply).

Returning multiple tokens, in contrast, enables a server to say use these (“pre-dropped”) tokens at these API endpoints. No extra discovery is required. No extra service-specific knowledge is required of clients.

‘Dropping privileges’ is nice additional functionality, but I don’t think it is a good alternative to returning multiple tokens.

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Jun 2010 18:56:33 -0700

This use case seems to have some support for an extension, but enough resistance for being added to core. I suggest those who care about this write a proposal as an I-D.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Wednesday, June 16, 2010 6:54 PM
To: Breno
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow

Breno,

--
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 17 Jun 2010 13:30:23 +0200

I'm going to write an I-D for multiple access tokens. If someone else 
would like to contribute, please contact me.

regards,
Torsten.

Am 17.06.2010 03:56, schrieb Eran Hammer-Lahav:
>
> This use case seems to have some support for an extension, but enough 
> resistance for being added to core. I suggest those who care about 
> this write a proposal as an I-D.
>
> EHL
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Manger, James H
> *Sent:* Wednesday, June 16, 2010 6:54 PM
> *To:* Breno
> *Cc:* OAuth WG ([email-masked])
> *Subject:* Re: [OAUTH-WG] proposal: multiple access tokens from a 
> This alternative (dropping privileges) could work for clients that 
> know everything about a service: which scopes are necessary & 
> sufficient for each call, and that ‘dropping privileges’ is supported. 
> It requires lots of service-specific knowledge in the client, and/or 
> some reasonably sophisticated discovery (which is so far undefined, 
> untried, and not obvious how it should be done). A service that 
> *requires* dropped privileges can only reject calls that use full 
> tokens (and hope that hasn’t already compromised security), and hope 
> that clients can then discover how to drop privileges and what to drop 
> them to (efficiently & simply).
>
> Returning multiple tokens, in contrast, enables a server to say use 
> these (“pre-dropped”) tokens at these API endpoints. No extra 
> discovery is required. No extra service-specific knowledge is required 
> of clients.
>
> ‘Dropping privileges’ is nice additional functionality, but I don’t 
> think it is a good alternative to returning multiple tokens.
>
> -- 
>
> James Manger
>
>