Right, SHOULD NOT is fine. I am just asking not to make it a MUST NOT. 2015-07-24 17:47 GMT+09:00 Brian Campbell <bcampb...@pingidentity.com>:
> PCKE prevents a bad app from using the code when there's a collision in > the custom scheme used for the redirect URI. However the same app could > immediately issue a new authorization request with it's own PCKE parameters > and (mostly) transparently get back a code that it can use. Having some > user interaction via the browser helps mitigate that. > > 6.4 says that "tokens SHOULD NOT be issued to such [non-confidential] > clients without user consent or interaction" so it's not strictly required. > > Also, FWIW from http://tools.ietf.org/html/rfc2119 SHOULD NOT and NOT > RECOMMENDED are effectively synonymous > > On Fri, Jul 24, 2015 at 9:44 AM, Nat Sakimura <sakim...@gmail.com> wrote: > >> 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 >> >> > -- 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
