Torsten, I really like this use case. I think it ought to be documented on its own. (But please let me know if you disagree and thing that it is a subset of another use case.)
I also see potential synergy with the recursive delegation case. For my use-cases draft, I am trying to develop a common template for all use cases. In a day or two, I am going to send your case described in this template to check your opinion. Zachary -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Tuesday, April 06, 2010 1:01 PM To: oauth@ietf.org Subject: [OAUTH-WG] Access Token Exchange Flow Hi all, here at Deutsche Telekom, we see the need for a flow supporting the exchange of access tokens for one service into access tokens for another service. The scenarios is as follows: In the context of mobile applications, we employ multi-layered architectures of personalized web services. The first layer typically exposes an API optimized for the flows of a particular application. This layer's business logic is built on top of other web services and so on. We use self-contained bearer tokens carrying id's, attributes and permissions. Each of the web services involed has a trust relationship with our authorization server based on shared secrets. Every web service requires a different token with different claims (id, permissions, attributes) and signature (HMAC). The flow is as follows: 1) The client acquires a token for the first service eather by username/password authentication or web-based authorization flow. 2) The client sends a request (including the access token) to the first web service. 3) Access control and some business logic is executed based on the token contents. Afterwards, the first service determines that it needs to call another services (second web service) on behalf of the user. 4) It requests the issuance of a new token for the second service from the authorization server based on the original token sent by the client. 5) The authorization server issues a new token carrying the claims need by the second web service and digitally signs the token with the respective shared secret. It also encrypts the token content in order to prevent the first web service from eavesdropping the users data intended for the second service only. 6) The first web service uses the token to invoke the second web service. ... Does anyone else see the need for such a flow? 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
