[Openid-specs-native-apps] Web Browser news from WWDC

Nat Sakimura sakimura at gmail.com
Mon Jun 15 22:50:48 UTC 2015 

What I am still vague on is that how the callback from the browser tab
works.
(Please provide me with a documentation/video links if there is one.)

Does a regular OAuth callback work?
In which case, what redirect_uri it should use?

Nat

2015-06-16 6:56 GMT+09:00 William Denniss <wdenniss at google.com>:

> URL claiming is definitely a huge advancement, finally we can get some
> assurances of the identity of the app receiving the token (and not just
> that the token went back to the requesting app which PKCE ensures).  In
> Android, Apps Links
> <http://developer.android.com/preview/features/app-linking.html> are a
> platform feature, so the rollout will take longer.  Chrome Custom Tabs
> however will soon be available
> <https://support.google.com/chrome/answer/2393487?hl=en> on devices back
> to Android 4.1+ (Jelly Bean).  Both these features start to bring the
> native app and mobile web experiences closer together.
>
> It does look like it will be possible to basically insert a native TA into
> the process, simply by claiming the the auth URL.  Given this, I believe we
> can write a spec for doing OAuth on Mobile without needing to spend a lot
> of time on the Native TA part.
>
> Starting in 'seed 2' of iOS 9 (not yet available), the app association
> file (required for Universal Links) will no longer need to be signed using
> the same key as the SSL certificate which will make this a lot more
> accessible for developers.
>
> One thing to note is that SFSafariViewController is still in beta, and
> they are explicitly seeking feedback. So if we think something is missing
> now is the time to ask for it.
>
> On Mon, Jun 15, 2015 at 2:21 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>> In principal closing the tab with a universal link could act as a
>> replacement for validating the app bundle_id effectively the same way the
>> https redirect URI validates the identity of a web  server.
>>
>>
>> That might be logically simpler than trying to validate and track
>> bundle_id and signer.
>>
>> We need to see if it works in practice.
>>
>> This is sort of the same thing Google is doing in smart lock so that a
>> native app and website can share the same password info.
>>
>> John B.
>>
>>
>> On Jun 15, 2015, at 12:34 PM, David Waite <david at alkaline-solutions.com>
>> wrote:
>>
>> WebKit controls allow you to hook into events and inject javascript, but
>> as a consequence you are running with a separate copy of user state.
>>
>> The new control is effectively a Safari tab which pops up over your UI. I
>> don’t believe you can do too much more than tell it what page to start at,
>> or programmatically dismiss it. But, it is supposed to have all the state
>> and credential access of the system browser. Among other things, you cannot
>> control what browser controls are visible to the user, which include a
>> non-editable address bar and a dismissal button.
>>
>> This does not provide new functionality, but could substantially improve
>> the UX. The user gets a modal popup rather than bouncing to/from the system
>> browser, and has a button to cancel/dismiss and be returned exactly where
>> they started. The user also doesn’t wind up with additional MobileSafari
>> tabs left behind by the authentication process.
>>
>> Apple explicitly called this out as useful for OAuth in their
>> presentation. They proposed the use of custom URLs to close it, however I
>> wonder if universal links (also new in ios 9) would work and be a better
>> option.
>>
>> Universal links allow your website to give permission for one or more
>> apps to be used to service particular resource paths. These apps have to be
>> provisioned with the domains which they are willing to service (so no
>> universal TA).
>>
>> On requesting the URL, the system will skip safari and transition
>> directly to your app. There appears to be an interface to return back to
>> the originating app as well, as if the new app was a new card on top of the
>> navigation view stack.
>>
>> This allows you to control a single app to be called on use of a URL, a
>> single ownership semantic Apple is unwilling to provide on iOS. It also
>> allows for a fallback - if the app isn’t installed, the user is sent to the
>> page in Safari. From there, you could use app banners to advertise the
>> token agent app as a better experience.
>>
>> It remains to be seen through experimentation if these work well or if
>> they work well together. But it may be we got a way to invoke a TA and
>> automatically fall back to an in-place web view if it isn’t installed, a
>> better UX overall, and that we got a way to more securely redirect back to
>> the app when finished.
>>
>> -DW
>>
>> On Jun 15, 2015, at 7:08 AM, Mike Varley <mike.varley at securekey.com>
>> wrote:
>>
>>  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 :)
>>
>>  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.
>>
>>  MV
>>
>>   On Jun 15, 2015, at 8:50 AM, Paul Madsen <paul.madsen at gmail.com> wrote:
>>
>>  hey Mike, if true, you are saying the new tabs can 'do everything the
>> system browser does', so the only difference is UX
>>
>> Im not diminishing the importance of the UX , just want to understand
>> what we gain
>>
>> On 6/15/15 8:36 AM, Mike Varley wrote:
>>
>> 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.
>>
>>  MV
>>
>>
>>
>>  On Jun 15, 2015, at 8:05 AM, Paul Madsen <paul.madsen at gmail.com> wrote:
>>
>>  John, can you expand on
>>
>> 'However it seems like we will be able to do significantly more with the
>> browser than we had been thinking.'
>>
>> As I see it, the new feature doesn't enable anything *more* other than a
>> better UX on iOS? True?
>>
>> Paul
>>
>> On 6/12/15 4:38 PM, John Bradley wrote:
>>
>> Have a look at 23min into this video from ADC.
>>
>>  https://developer.apple.com/videos/wwdc/2015/?id=504
>>
>> This is a significant development.
>>
>>  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.
>>
>>  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.
>>
>>  People should look at the ACDC draft
>> https://bitbucket.org/openid/napps/wiki/Home.
>>
>>  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.
>> For SasS we may be able to use OAuth + ACDC and discovery in a tab.
>>
>>  It looks like the tab will have access to device certificates solving
>> some peoples issues around that.
>>
>>  We should also be able to do accountchooser.com in the browser tab to
>> perform account discovery.
>>
>>  Now that the changes have landed on iOS and Android we should be good
>> to do testing in the late summer fall.
>>
>>  Please start the discussion on the list.
>>
>>  I recognize that some people will still have use cases for native token
>> agents, so I am not proposing completely eliminating that yet.
>>
>>  However it seems like we will be able to do significantly more with the
>> browser than we had been thinking.
>>
>>  Regards
>> John B.
>>
>>
>>
>> _______________________________________________
>> Openid-specs-native-apps mailing listOpenid-specs-native-apps at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>
>>
>>  _______________________________________________
>> Openid-specs-native-apps mailing list
>> Openid-specs-native-apps at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>
>>
>>
>>
>>   _______________________________________________
>> Openid-specs-native-apps mailing list
>> Openid-specs-native-apps at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>
>>
>> _______________________________________________
>> Openid-specs-native-apps mailing list
>> Openid-specs-native-apps at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>
>>
>>
>> _______________________________________________
>> Openid-specs-native-apps mailing list
>> Openid-specs-native-apps at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>
>>
>
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20150616/8b6f6726/attachment-0001.html>

More information about the Openid-specs-native-apps mailing list