Eric Rescorla has entered the following ballot position for draft-ietf-oauth-native-apps-11: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Document: draft-ietf-oauth-native-apps-11.txt S 7. To fully support this best practice, authorization servers MUST support the following three redirect URI options. Native apps MAY use whichever redirect option suits their needs best, taking into account platform specific implementation details. It's not entirely clear from this text what "support" means. Would just echoing whatever redirect URI the client provided count as support? S 7.2. App-claimed HTTPS redirect URIs have some advantages in that the identity of the destination app is guaranteed by the operating system. For this reason, they SHOULD be used in preference to the other redirect options for native apps where possible. You should probably be clearer on who this guarantee is provided to. And I assume this SHOULD is directed to app authors? Claimed HTTPS redirect URIs function as normal HTTPS redirects from the perspective of the authorization server, though as stated in Section 8.4, it is REQUIRED that the authorization server is able to distinguish between public native app clients that use app-claimed HTTPS redirect URIs and confidential web clients. S 8.4 doesn't seem clear on how one makes this distinction. Is it just a matter of remembering what the app author told you? S 8.1. As most forms of inter-app URI-based communication send data over insecure local channels, eavesdropping and interception of the authorization response is a risk for native apps. App-claimed HTTPS redirects are hardened against this type of attack due to the presence of the URI authority, but they are still public clients and the URI is still transmitted over local channels with unknown security properties. I'm probably missing something, but I'm not sure what this last sentence means. Is the channel here the one that kicks off the native app with the HTTPS URI as the target? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
