[Openid-specs-native-apps] Notes from Oct 30 NAPPS Meeting

[William Denniss]

Hi All,

We had a solid week of working sessions last week. Here are my notes from
the final meeting on Thursday at IIW.

Present at the very end were: John Bradley, Nat Sakimura, Lloyd Burch,
Emily Xu, Ashish Jain and William Denniss.  (sorry, I don't have a roll
call for the whole meeting, please feel free to reply and add your name
plus any comments/notes!)


Whiteboard images posted here:
https://plus.google.com/+WilliamDenniss/posts/7aqRumjEaSY?pid=6079042534008594978&oid=109917506981759115980

This latest proposal is for NAPPS to use regular OAuth 2.0 flows (protected
with spop <https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/> [latest
draft <https://bitbucket.org/wdenniss/oauth-spop/downloads>]) with
enhancements to improve SSO on native platforms.

It was discussed that the Token Agent could basically be the broker of the
OAuth "code", and could be the location where the all the business logic
around re-authentication is located (potentially both client and server
side logic).

For example, if if the user is required to re-authenticate at the start of
the day, the TA can facilitate that. Subsequent calls can then mint new
codes as per the relevant business logic (e.g. device must have a passcode,
or touchID must be entered at the TA to continue).


Both a Native App and the System Browser can potentially play the role of
the TA, as their inter-app sharing I/O is similar (custom URL schemes).
The pros and cons were discussed of each model. The attendees were roughly
split 50:50 on those who would likely consider a native token agent, and
those who preferred the system browser. The NAPPS spec could document both
profiles, with some suggestions to help guide people to one or the other.
Here's a list of some pros and cons that were discussed ('+' is a pro, '-'
is a con):

Native TA:

+ Can protect against a bad calling app (as it knows the calling bundle ID)

- Unable to protect against a bad TA (the bad TA can register the same URL
scheme as the real TA)

+ Ability to make native calls, for example to require TouchID to unlock
the master token

+ Can enforce "lightweight MDM" such as determining if the user has a
Passcode / Lockscreen.

- Must be installed by the user

System Browser:

+ Protects against a bad TA ("https://" calls will only open the system
browser)

- Unable to protect against a bad calling app, as the callers Bundle ID is
not known

+ Can be presented on the homescreen via a configuration profile
<https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html>
(which can also bundle certificates, etc)

+ Available on every device, and may be required as a fallback anyway

Both profiles have the ability for a "launcher" style page for enterprise
apps.  Both have the same I/O capabilities for inter-app communication (URL
schemes).


If there is broad agreement on the diagrams & description above, we can
start to document the functionality of the TA, and then look at questions
such as TA discovery and app-info lists. I'll volunteer to work on the API
bindings spec, including the Native TA and System Browser TA profiles.


Best,
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20141107/4ea7ad13/attachment.html>