Hi, Thanks for the great work of putting this together. I have a few comments on the current draft. See below
Best Regards Samuel Erdtman 5. Using Inter-app URI Communication for OAuth The end of this section is a bit confusing with first a MUST statement and then a RECOMMENDED statement “Native apps MUST use an external user-agent to perform OAuth” and “This best practice focuses on the browser as the RECOMMENDED external user-agent for native apps.” 7.1.1. Custom URI Scheme Namespace Considerations “For example, an app that controls the domain name "app.example.com" can use "com.example.app:/" as their custom scheme.” drop the slash in the custom schema. 7.2. App-claimed HTTPS URI Redirection “When the browser encounters a claimed URL, instead of the page being loaded in the browser, the native app is launched instead with the URL supplied as a launch parameter.” drop one “instead” changing it to: “When the browser encounters a claimed URL, instead of the page being loaded in the browser, the native app is launched with the URL supplied as a launch parameter.” 7.2. App-claimed HTTPS URI Redirection If this is the recommended way to do it when possible maybe it should be first? 8.1. Embedded User-Agents “Embedded user-agents are an alternative method for authorization native apps.” change to “Embedded user-agents are an alternative method to authorize native apps.” or “Embedded user-agents are an alternative method for authorization of native apps.” 8. Security Considerations I see normative language here (MUST, RECOMMENDED, SHOULD, etc.), and it felt a bit odd to me to have that under Security Considerations. Not sure if there are guidelines around that, but to me it would make sense to keep the normative parts out of Security Considerations. And it says “Considerations”, to me that sounds mor like things to think about then this is how it works. 8.2. Protecting the Authorization Code “A limitation of using custom URI schemes for redirect URIs is that multiple apps can typically register the same scheme, which makes it indeterminate as to which app will receive the Authorization Code. PKCE [RFC7636] details how this limitation can be used to execute a code interception attack (see Figure 1). Loopback IP based redirect URIs may be susceptible to interception by other apps listening on the same loopback interface.” I think it would be preferable to separate custom URI and Loopback IP based redirect. 8.2. Protecting the Authorization Code “Loopback IP based redirect URIs may be susceptible to interception by other apps listening on the same loopback interface.” Are you referring to an application listening to loopback traffic or an application killing the original application and start listening on the same port. The second alternative would be relatively intrusive and notable. Appendix A. Server Support Checklist 1. Support custom URI-scheme redirect URIs. I could not see that this was required in section Section 7.1. Appendix A. Server Support Checklist 5. Support PKCE. in Section 8.2 it says MUST “Authorization servers MUST support PKCE [RFC7636] for public native app clients.”
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
