<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes having a MDM provision down the information to the app would be the preferable option.<div class=""><br class=""></div><div class="">I don’t think all TA using the same URI is necessarily the correct thing. There may be cases where you have a social TA for some apps and a enterprise TA for other apps on the same device.</div><div class=""><br class=""></div><div class="">Will some IdP be willing to share token agents in the social case. That may be true if it is part of the OS, but perhaps not if it is an app. Also native app TA will need client credentials for each IdP as well.</div><div class=""><br class=""></div><div class="">At the moment we have an assumption of one uri scheme for invoking the TA. Bad things happen if you get two TA installed by mistake. </div><div class=""><br class=""></div><div class="">If we have multiple TA they need to use the system browser to share state or be dedicated to an IDP if they are using a embedded web view.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2014, at 5:12 PM, <a href="mailto:KabirBarday@air-watch.com" class="">KabirBarday@air-watch.com</a> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252" class="">
<div dir="auto" class="">
<div class="">On iOS the common URL scheme may have some issues, iOS allows multiple apps to register the same URL scheme and will auto select one, the user does not get to pick. The logic for which app iOS selects is arbitrary. This also opens up a security issue where
a malicious app may be installed, registers for the TA url scheme, and then intercepts the credentials the end user enters in the fake TA.</div>
<div class=""><br class="">
</div>
<div class="">With MDM, both iOS and android have the ability for MDM vendors to send app configuration into the app. On iOS it is called managed NSUserDefaults, and on android it is called App Restrictions. The configuration can indicate which TA to use in some way,
and there is a standard way for app developers to listen to these configs on both iOS and android (Msft is working on a similar approach also). This may make it a better user experience when deployed with MDM, but will need some fall back logic when no MDM
in place. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class=""><span style="background-color: rgba(255, 255, 255, 0); font-size: 13pt;" class="">Kabir Barday</span></div>
C | 404.913.4120
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><a href="mailto:KabirBarday@air-watch.com" class="">KabirBarday@air-watch.com</a></span><br class="">
<div class=""><br class="">
</div>
<div class="">Sent from my device managed by AirWatch
<div class=""><a href="http://www.air-watch.com/" class="">www.air-watch.com</a></div>
</div>
</div>
</div>
<div class=""><br class="">
On Nov 27, 2014, at 10:10 AM, Mike Varley <<a href="mailto:mike.varley@securekey.com" class="">mike.varley@securekey.com</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class=""><span class="">Hi John,</span><br class="">
<span class=""></span><br class="">
<span class="">I believe you have highlighted 2 different scenarios:</span><br class="">
<span class=""></span><br class="">
<span class="">1) A closed ecosystem, where a large organization has several apps that rely on a single token/authenticationagent. (lets say all Apps and the TA have the same brand)</span><br class="">
<span class="">2) SaaS Apps that want to leverage a user's token agent, but are multi-purpose (mail service, doc management, etc…)</span><br class="">
<span class=""></span><br class="">
<span class="">in (1) I believe hard-coded custom URL schemes or custom discovery systems will work fine. The closed ecosystem sets the rules and follows them.</span><br class="">
<span class=""></span><br class="">
<span class="">So considering (2), the SaaS App needs to discover a TA. And there are a couple options:</span><br class="">
<span class=""></span><br class="">
<span class="">(A) All eligible TA's register for the same scheme (e.g. nativeapp://)</span><br class="">
<span class="">(B) SaaS App need to be able to customize themselves for a user's organization</span><br class="">
<span class=""></span><br class="">
<span class="">I see (A) as being a more flexible option, if the corners aren't too sharp. For example, if I as a user have installed Box, and have 2 TAs installed (one for work and one for a club I am in), then when Box launches, it invokes the common URI (<a href="nativeapp://authorize" class="">nativeapp://authorize</a>),
and on Android I think this will allow the user to select the TA they wish to use. The advantage here is Apps and TAs have very clear, simple requirements to be NAPPS enabled. The problem is, I don't think all the mobile OS's treat multiple apps registered
for a URI scheme the same (i.e. can anyone confirm that on iOS, the 'latest' App to register for a scheme becomes the default?). </span><br class="">
<span class=""></span><br class="">
<span class="">If mobile OS's are not going to allow for (A) (cleanly), then (B) is the better option, and a bootstrapping process described below is reasonable. A few thoughts on the process:</span><br class="">
<span class=""></span><br class="">
<span class="">- should the user authenticate to the endpoint before the ecosystem config is released? Would it make sense that a SaaS App allows the user to login in with OpenID Connect, and part of the id_token/userinfo then contains the TA information?</span><br class="">
<span class=""></span><br class="">
<span class="">- does this mean a user must bootstrap *every* SaaS App on their device to use a TA? [ seems like a painful process ].</span><br class="">
<span class=""></span><br class="">
<span class="">- how much extra dev work are we imposing on SaaS Apps that may want to be NAPPS enabled?</span><br class="">
<span class=""></span><br class="">
<span class=""></span><br class="">
<span class="">Thanks,</span><br class="">
<span class=""></span><br class="">
<span class="">MV</span><br class="">
<span class=""></span><br class="">
<span class=""></span><br class="">
<span class=""></span><br class="">
<span class="">On Nov 26, 2014, at 5:12 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" class="">ve7jtb@ve7jtb.com</a>> wrote:</span><br class="">
<span class=""></span><br class="">
<blockquote type="cite" class=""><span class="">At IIW this was one of the questions that we didn’t get to other than to say that it is required in some way.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">A napps client needs to know what TA to invoke. </span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">If there can only be one TA on the device and they all use the same custom scheme then I suppose that discovery is moot.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">If we have a SAAS app like box then I could see wanting to customize the TA per enterprise.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">The app could call a well known endpoint and get the config for the enterprise eg custom URI to invoke. (The app wouldn’t have credentials at that point so this would be public.)</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">The other sort of app may be a generic app that uses a standard API at the enterprise, but doesn’t know who the enterprise is without some bootstrap.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">One way to deal with this is to have the user enter a domain to bootstrap the app.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">It can then use a similar process to Connect discovery to find the enterprise napps config file in .well-known.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">The file would list the client_id and custom scheme for a token agent and a fallback https: URI for using the browser.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">This requires the same infrastructure as they would already have in place for Connect Discovery.
</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">This also works for the saas app as long as the enterprise publishes the discovery doc the saas app could pick up the config info.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">The downside of the SAAS publishing it, is that they generally don’t like publishing lists of customers.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">Are there other things that need to be discovery at this stage.
</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">I think NAPPS discovery should start as a separate document and we can merge them later if we want to.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">Not all apps will need it, some can be hard coded if they are developed by an enterprise directly.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">Thoughts</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">John B.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">_______________________________________________</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class="">Openid-specs-native-apps mailing list</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""><a href="mailto:Openid-specs-native-apps@lists.openid.net" class="">Openid-specs-native-apps@lists.openid.net</a></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" class="">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a></span><br class="">
</blockquote>
<span class=""></span><br class="">
<span class="">_______________________________________________</span><br class="">
<span class="">Openid-specs-native-apps mailing list</span><br class="">
<span class=""><a href="mailto:Openid-specs-native-apps@lists.openid.net" class="">Openid-specs-native-apps@lists.openid.net</a></span><br class="">
<span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" class="">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a></span><br class="">
</div>
</blockquote>
</div>
</div></blockquote></div><br class=""></div></body></html>