btw can any of the Microsoft folks on the list give any indication if IE has plans to do something similar to custom tabs / safari view controller for windows devices? Maybe it's not something you can comment on, but at least let it be know the interest is out here :-)
On Wed, Jul 15, 2015 at 8:38 PM, Adam Lewis < adam.le...@motorolasolutions.com> wrote: > Hi Chuck, > > ACDC + PKCE is what we want to do as well. It is a perfect fit for first > responders accessing APIs in foreign security domains. > > The custom tabs / safari view controller provides an extremely elegant > means to do SSO across both native & web, utilizing session cookies in the > browser. > > But ACDC is a bit more elegant from a UX vantage since it is all > back-channel. > > Of course where user input it required than the custom tabs / view > controller might be better since the user can hit the authorization > endpoint and interact with the AS. This assuming that IdP discovery is > seamless, and doesn't result in the user being confused by a NASCAR or > dropdown list or other kludgy UI on the HTML returned from the foreign AS > to the mobile's browser. > > I think that ACDC will be a better fit for enterprise scenarios where the > RO is the enterprise (not the end user) vs. doing OIDC to the foreign AS > authorization endpoint. > > My 2 cents. > adam > > On Wed, Jul 15, 2015 at 7:57 PM, Chuck Mortimore < > cmortim...@salesforce.com> wrote: > >> On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones <michael.jo...@microsoft.com> >> wrote: >> >>> I assume that TokenService1 is an OpenID Connect Provider, since it’s >>> issuing both an access token and an ID Token, correct? >>> >> >> Correct. >> >> >>> >>> >>> I assume that you want the interaction with TokenService2 to not include >>> any user interaction – that that’s where you’re doing the Token Exchange – >>> correct? >>> >> >> Correct. >> >> >>> >>> >>> How did you envision the Client authenticating to TokenService2? Is it >>> a registered OAuth 2.0 client at TokenService2 using a Client >>> Authentication method? Is it signing a request to TokenService2 and >>> TokenService2 validates and trusts the signature by Client? Is no >>> authentication performed other than being in possession of the ID Token >>> serving as proof that the requester has necessary rights to do the token >>> exchange? Or some combination of these…? >>> >> >> We're thinking it may be a combination, but standard OAuth techniques >> will likely be the easiest for the third party service to digest. The >> most basic use-cases would probably just be possession of the ID token. I >> do like the ACDC addition of the PKCE to the token material to at least >> bind it to client though. >> >> >> >>> >>> >>> Knowing your use case is really valuable. Thanks for describing it for >>> us. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Chuck Mortimore [mailto:cmortim...@salesforce.com] >>> *Sent:* Wednesday, July 15, 2015 2:44 PM >>> *To:* Anthony Nadalin >>> *Cc:* OAuth WG; Mike Jones >>> *Subject:* Re: [OAUTH-WG] Use of Token Exchange spec for API Federation >>> >>> >>> >>> 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
