Hi,

Thanks for a great document! I volunteered to review
draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:

In national mobile eID deployments an app is issued by gov or other
organisation in a country. The app acts as the users authentication method
and it works with an IDP, the IDP can be anywhere if its an PKI token or at
the place that issued the credential if it’s something else. When an SP
start developing an native app for there services and want’s to use the
national eID solution in combination with OAuth we might run into trouble
here.

The flow is like follows for a service provider called FooBar:

FooBar’s app starts browser-view. FooBar’s SAML service provider
functionality redirects the user to an national SAML IDP. The IDP prompts
user for a username and then starts an mobile eID token on the same phone.
Users is asked if they want’s to authenticate to FooBar and enters PIN.
User are then redirected back with an assertion. The FooBar's service
provider verifies the assertion and mint’s OAuth2 token(s) and redirects
the user back to the app with the help of the redirect URL.

So the phone first displays an app, then foobar.com <http://example.com/> in
browser-view, then idp.com <http://nationalidp.com/> in *browser-view*,
then mobile eID token, then idp.com <http://nationalidp.com/> in the *system
browser* and back to foobar.com <http://example.com/> and the app that the
user wanted to use.

The problem with browser-views is that the mobile eID token will start
idp.com when user has authenticated and then the user is not back in the
apps browser-view, but in system browser instead. The system browser is
sharing the session with the browser-view and redirect the user to the
native app. The user experience will be a bit strange then because there
the correct page is not loaded and the browser-view should be closed and
the app should start parsing out the authorization code instead.

So I think draft should mention something about this scenario and that app
developers should handle this scenario in the app. The grant did not really
come back from the browser-view as expected but from the system browser
instead.

—————————

With the above in mind. Maybe even some example code would be nice to have
in the non normative section "Appendix A.  Operating System Specific
Implementation Details”. Especially how to handle call backs.

—————————

Another eID related issue is the pricing model for authentications in that
market segment. It’s really common by the eID credential issuing
organisations to charge a service providers usage of a credential per tick
(that is by OSCP call). The system is based on a per tick pricing model and
there are regulations for how long the sessions can live. That means that
its not possible to authenticate with a token once and then create a
refresh token and the user will ever see the authentication flow again. It
kinda messes up the usability of mobile apps a lot but end users have come
to term with it. They have not however came to term to always require
consents every time they use the app. That drives end user crazy. The
usability would be much better if the payment model also accepted a refresh
token as a tick instead of just an OSCP call, but we are not there yet.

Anyway, that’s the backstory. The section "6.4.  Always Prompting for User
Interaction” is a bit harsh with a SHOULD NOT. I would rather change it to
a NOT RECOMMENDED.

—————————

Two additional things that strengthen the case for using the browser-view
also come to mind when reading the draft. The first is the fact that
multiple tabs is started in some browser when going through multiple
authentication attempts. That clutters the system so I really like the new
browser-views.

The second is that there are additionally nice things in browser-view that
do not exist in the web-view. The localStorage is also preserved and it can
include important information to make authentication methods more secure.

————————

"Authorization servers SHOULD consider taking steps to detect and

block logins via embedded user-agents that are not their own, where

possible.""


Sounds good, but that also sounds very hard when it comes to public
clients.

—————————

And some nits:


"OAuth flows between a native app and the system browser (or another

external user-agent) are more secure, and take advantage of the

shared authentication state."


Not really clear what shared authentication state that is in that sentence.


"When the authentication server completes the request, it redirects to

   the client's redirection URI like it would any redirect URI"


s/authentication/authorization


/ Erik




On Thu, Jul 23, 2015 at 6:22 PM, <oauth-request@ietf.org> wrote:
>
>
> John Bradley and I introduced a new draft at IETF93 yesterday:
> https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00
>
>
> Goal is to provide best practices for native apps using the RFC6749
> authorization
> endpoint, expanding on RFC6749 Section 9.  Specifically, it recommends
> using an external user-agent (such as the system browser) for this task
> over an embedded user-agent (such as a web-view), and suggests ways to
> achieve this.
>
>
> Comments welcome!