Thanks Adam - ACDC looks like it's targeted at our use-case. Potentially a little more difficult to layer on to our infrastructure, but looks workable.
Does this spec live in OIDC Napps? If so, I'll head over there to ask a few questions -cmort On Wed, Jul 15, 2015 at 3:07 PM, Adam Lewis < adam.le...@motorolasolutions.com> wrote: > Hi Chuck, > > Wouldn't the ACDC be a closer fit to what you are doing? Not saying token > exchange couldn't work, but ACDC is specifically targeting your use case. > > -adma > > On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore < > cmortim...@salesforce.com> wrote: > >> User logs into Client and accesses Resource1 using AccessToken1 from >> TokenService1. >> >> Client then contacts TokenService2 and exchanges IDToken1 from >> TokenService1 for AccessToken2 from TokenService2. It then uses >> AccessToken2 to access Resource2. >> >> -cmort >> >> >> >> On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <tony...@microsoft.com> >> wrote: >> >>> 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 >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
