Yes it is a NAPPS thing. The pressure for it has been reduced by the release of the Safari view controller and Chrome custom tabs.
However it still has uses for IoT and some other places. It would be best if somehow that could align with the other token exchange proposals. PKCE just went in to the RFC editor que, and ACDC waits to see if there is enough demand. John B. > On Jul 15, 2015, at 11:38 PM, Chuck Mortimore <cmortim...@salesforce.com> > wrote: > > 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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto:oauth-boun...@ietf.org>] > On Behalf Of Chuck Mortimore > Sent: Wednesday, July 15, 2015 12:47 PM > To: OAuth WG <oauth@ietf.org <mailto:oauth@ietf.org>>; Mike Jones > <michael.jo...@microsoft.com <mailto: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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
