<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="">There are two features that will both be available on iOS and Android.<div class=""><br class=""></div><div class="">One id giving a native app the ability to invoke a system browser tab with access to all the certificates and other cookie/local storage.</div><div class=""><br class=""></div><div class="">The other new feature is allowing apps to claim https: URI. </div><div class="">It works slightly differently on iOS and Android but the result seems to be largely the same.</div><div class=""><br class=""></div><div class="">Once you install a app that has claimed a URI that URI is now treated as special by the browser. </div><div class="">On iOS Apple has always special cased the URI for YouTube and had the browser redirect them to the app.</div><div class=""><br class=""></div><div class="">So you could imaging a AS that uses plain OAuth + PKCE or OAuth + ACDC via browser call in a web Tab that involves no UI flip and is 100% apple approved.</div><div class=""><br class=""></div><div class="">The AS could distribute a native token agent app that claims the URI of the web AS.</div><div class=""><br class=""></div><div class="">The app would transparently just start working with the Native Token Agent. </div><div class=""><br class=""></div><div class="">What I don’t know is what happens if two apps claim the same URI etc.</div><div class=""><br class=""></div><div class="">The other thing to consider is that with Fido 2.0 it will have a JS API and may work just as well from JS browser tab as from a native app.</div><div class=""><br class=""></div><div class="">There is also a attestation API on Android, that a calling app could possibly use to prove it’s bundle id etc on the device using the browser flow.</div><div class="">I don’t yet know if Apple will have something similar.</div><div class=""><br class=""></div><div class="">So as a thought experiment, what if doing NAPPS from the app point of view is just the OAuth code + PKCE or OAuth + ACDC plus a possible app attestation.</div><div class=""><br class=""></div><div class="">SaaS apps would still need discovery/MDM to know what enterprise to talk to, but basically any enterprise app doing code + pkce would just work, and can transparently be redirected to a native token agent if desired.</div><div class=""><br class=""></div><div class="">Or I suppose we could decide that if we can get 99% of what we want without a native token agent. If that is the case then perhaps some things could be simplified.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 15, 2015, at 10:08 AM, Mike Varley <<a href="mailto:mike.varley@securekey.com" class="">mike.varley@securekey.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Right - from what I understand the new tabs do everything the system browser does, and allows access to system browser state. But I only know what I saw from the keynote :)
<div class=""><br class="">
</div>
<div class="">So improved UX, not only from a buttons and tabs perspective, but the user's state is now accessible from the system browsers as well. </div>
<div class=""><br class="">
</div>
<div class="">MV<br class="">
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div class="">On Jun 15, 2015, at 8:50 AM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com" class="">paul.madsen@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">hey Mike, if true, you are saying the new tabs can 'do everything the system browser does', so the only difference is UX<br class="">
<br class="">
Im not diminishing the importance of the UX , just want to understand what we gain<br class="">
<br class="">
<div class="moz-cite-prefix">On 6/15/15 8:36 AM, Mike Varley wrote:<br class="">
</div>
<blockquote cite="mid:BD9B5F5F7BF17E45B0994CB86E1F9BFD8EEED063@DR-EXCH-01.devl.securekey.local" type="cite" class="">
I seem to recall that both iOS and Android will now allow these embedded web views (i.e., chrome tabs and safari web views) full access to the user's settings: including cookies, stored passwords, local storage, (device certificates as John mentioned), touchID?
the works. And there is the improved UI experience as well, that you pointed out, with "back' buttons that automatically return the user to the calling App.
<div class=""><br class="">
</div>
<div class="">MV<br class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""> <br class="">
<div class="">
<div class="">On Jun 15, 2015, at 8:05 AM, Paul Madsen <<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com" class="">paul.madsen@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">John, can you expand on<br class="">
<br class="">
'However it seems like we will be able to do significantly more with the browser than we had been thinking.'<br class="">
<br class="">
As I see it, the new feature doesn't enable anything *more* other than a better UX on iOS? True?<br class="">
<br class="">
Paul<br class="">
<br class="">
<div class="moz-cite-prefix">On 6/12/15 4:38 PM, John Bradley wrote:<br class="">
</div>
<blockquote cite="mid:29050B53-9529-4837-BA79-5F0521879627@ve7jtb.com" type="cite" class="">
Have a look at 23min into this video from ADC.<br class="">
<div class="">
<div class="">
<div class=""><br class="">
</div>
<div class=""><a moz-do-not-send="true" href="https://developer.apple.com/videos/wwdc/2015/?id=504" class="" style="font-family: Helvetica;
font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">https://developer.apple.com/videos/wwdc/2015/?id=504</a></div>
</div>
</div>
<br class="">
<div class="">This is a significant development.</div>
<div class=""><br class="">
</div>
<div class="">In talking to others from Google yesterday and today, they have introduced similar functionality in Android rolling out in approximately the same timeframe, and backwards compatible with current versions of Android.</div>
<div class=""><br class="">
</div>
<div class="">Being able to invoke a web tab without an app flip is a significant change, potentially making the TA in the browser that we have talked about the preferred option on iOS.</div>
<div class=""><br class="">
</div>
<div class="">People should look at the ACDC draft <a moz-do-not-send="true" href="https://bitbucket.org/openid/napps/wiki/Home" class="">https://bitbucket.org/openid/napps/wiki/Home</a>.</div>
<div class=""><br class="">
</div>
<div class="">It may be that NAPPS for enterprise is OAuth using a tab plus PKCE and some additional app verification logic + fido api in the browser.</div>
<div class="">For SasS we may be able to use OAuth + ACDC and discovery in a tab.</div>
<div class=""><br class="">
</div>
<div class="">It looks like the tab will have access to device certificates solving some peoples issues around that.</div>
<div class=""><br class="">
</div>
<div class="">We should also be able to do <a moz-do-not-send="true" href="http://accountchooser.com/" class="">
accountchooser.com</a> in the browser tab to perform account discovery.</div>
<div class=""><br class="">
</div>
<div class="">Now that the changes have landed on iOS and Android we should be good to do testing in the late summer fall.</div>
<div class=""><br class="">
</div>
<div class="">Please start the discussion on the list.</div>
<div class=""><br class="">
</div>
<div class="">I recognize that some people will still have use cases for native token agents, so I am not proposing completely eliminating that yet.</div>
<div class=""><br class="">
</div>
<div class="">However it seems like we will be able to do significantly more with the browser than we had been thinking.</div>
<div class=""><br class="">
</div>
<div class="">Regards</div>
<div class="">John B.</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset> <br class="">
<pre wrap="" class="">_______________________________________________
Openid-specs-native-apps mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">
Openid-specs-native-apps mailing list<br class="">
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net" class="">Openid-specs-native-apps@lists.openid.net</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br class="">
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div></blockquote></div><br class=""></div></body></html>