Prompting is not necessarily is a good thing. It is very context specific, so please do not make it required.
Nat 2015-07-24 16:38 GMT+09:00 John Bradley <ve7...@ve7jtb.com>: > Hi Antonio, > > Thanks for the feedback. > > I agree that for non confidential clients, the user needs to be prompted. > It might be fair to just confirm the grants rather than resetting them > from defaults. > > I know some people are doing that, but I suspect that not everyone is. > > Good stuff. > > People should chime in with other things we need to consider. > > Thanks > John B. > > On Jul 24, 2015, at 9:00 AM, Antonio Sanso <asa...@adobe.com> wrote: > > hi, > > nice to see some work on this topic by the way! > > Couple of comments below inline > > On Jul 24, 2015, at 7:51 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > Thanks for the review Erik, > > We will go through it in detail and get back to you. > > I am working with a couple of governments on how a eID app could use the > self issued profile of OpenID Connect to issue tokens. > > There are also other out of band authentication apps that people use that > need to be considered. > > I think that the callback / redirect_uri can work if a custom scheme URI > or a app claimed https: URI is used. > > > Is there any example of “popular” custom scheme. One I have seen is > urn:ietf:wg:oauth:2.0:oob > Another common redirect_uri for native app I have seen is http://localhost > > One more comment. I strongly suggest for mobile app to have a really > strict consent screen policy. > Aka the authorization server MUST show the consent screen at every usage > and not remember the fact that the app has been already authorized. > > Just my 2 cents :) > > regards > > antonio > > > I agree that sniffing the URI in a web view creates a very confusing user > experience at the moment. It works better on Android than iOS 8 but is not > smooth in many cases. > > I personally use a out of band mobile authenticator for my enterprise > login that has exactly that problem, and requires me to manually switch > back to the calling app. > > Regards > John B. > > > > > On Jul 24, 2015, at 12:59 AM, Erik Wahlström <e...@wahlstromstekniska.se> > wrote: > > 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-requ...@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! > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
