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 > <mailto: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 > <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 >>> <mailto: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 <http://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 >>> <mailto: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 >>> <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 <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
