So in your scenario where you have client (c), user (u), resource (r) and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore Sent: Wednesday, July 15, 2015 12:47 PM To: OAuth WG <oauth@ietf.org>; Mike Jones <michael.jo...@microsoft.com> Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation We're examining the use of the Token Exchange spec for API federation use-cases, and are looking for some feedback. The basic use-case is as follows: Developer wants to build an Application that is a composite of backend services that span multiple security domains. For example, it's a combination of Salesforce data and their own backend services. The application is authenticated by Salesforce, and developer wants to exchange our ID Token for a token in the second security domain so that login / credentials are not required for the second back-end service. To do this, we're planning to add configuration for multiple audiences in our service, allowing the developer to receive a mutli-party ID Token. We may also add custom claims to facilitate mapping of identity across the services. Having logged into Salesforce, and received an ID Token, the developer would then call a Token Exchange service in the second security domain and exchange this ID token for a token specific to that domain. This allows for simple API federation use-cases without converging both APIs / backends on a common token format. Questions / Feedback 1) In the spec, "sub" is a required field. However, the application may not yet know who the subject is in the second security domain ( it first has to exchange the token ) One option might be to place the client_id of the application as issued by the second security domain, but that seems a bit off. Any advice? Should this be an Optional field? 2) Speaking of client_ids, if we don't use the "sub" to transport them, we believe the second security domain would still appreciate this context. The Actor field is available, but construction of a full JWT just to transport the client_id seems like high overhead, and it may not even be aligned with the intent of that field. Should client_id be a claim here? 3) Speaking of Actors, It's not clear what actually states that the jwt included in the token is actually an approved actor. Is it intended that the act_as or on-behalf_of tokens include an azp authorized party clam as well? 4) "Implementations of the specification MUST implement support for using JWTs as the Security Tokens. Other Security Token types MAY be supported." This seems antithetical to the purpose of an STS. We believe this should be relaxed to a SHOULD Thanks for any feedback here
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
