Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07

Denis <> Tue, 21 February 2017 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C929129529 for <>; Tue, 21 Feb 2017 00:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wbOe2G-yW0h2 for <>; Tue, 21 Feb 2017 00:50:09 -0800 (PST)
Received: from ( [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72A08129643 for <>; Tue, 21 Feb 2017 00:50:09 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTP id 3A5B8780375 for <>; Tue, 21 Feb 2017 09:50:07 +0100 (CET)
References: <> <>
From: Denis <>
Message-ID: <>
Date: Tue, 21 Feb 2017 09:50:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------88405DFA1529E72C9F36E848"
Archived-At: <>
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Feb 2017 08:50:12 -0000

I *don't thin**k* it's normal to have normative text in the Security 
Considerations, hence I support Samuel's position.

Let us look at the first MUST from RFC 6749 in the Security 
Considerations section:

    The authorization server*_MUST_ *authenticate the client_*whenever possible*_.

This sentence is incorrect. The right sentence should be :

    The authorization server*should *authenticate the client whenever possible.

RFC 6749 is not an example to follow.


> I do think it's normal to have normative text in the Security 
> Considerations.  RFC6749 has a lengthy Security Considerations section 
> <> with a lot of 
> normative text.
> Think of it this way: Sections 4 to 7 describe how to use native app 
> URI schemes to perform OAuth flows from the app to browser and back. 
> If you only read those sections, you could have a functioning (but 
> potentially insecure) OAuth flow in a native app. The security section 
> adds some security requirements and clarifications for implementing 
> Sections 4-7, like using PKCE, and more.
> Reviewing sub-section by sub-section:
> 8.1 Definitely belongs here, as the the whole BCP is about native-app 
> URI schemes, whereas doing OAuth in a WebView doesn't need those (as 
> the client can just pluck out the code from any redirect URI)
> 8.2 Requires that servers who want to follow the native apps BCP 
> support PKCE, and recommends that they reject requests from clients 
> who don't.  This *could* be in the main doc, but since PKCE is an 
> existing thing, and is purely additive from a security perspective, I 
> think this reference works fine. Originally I talked about PKCE more 
> in the doc body, but some reviewers thought it was then a little 
> duplicative of the PKCE doc itself.
> 8.3 This reads like classic security considerations to me, clarifying 
> some details of 7.3
> 8.4 Part of this reads a little new-ish, regarding distinguishing 
> native clients from web ones. But on review, I think could just be 
> re-worded to reference RFC6749 Section 2.1.
> 8.5 This one belongs where it is since the body of the BCP is talking 
> about the code flow.
> 8.6 Totally belongs.
> 8.7 to 8.11 belong IMO, they are security clarifications of 
> long-standing topics.
> My methodology when reviewing this was: is the text introducing a new 
> topic directly related to native apps or sections 4-7, or does it 
> discuss an old security topic in the context of native apps, or add 
> security related discussions of the content in 4-7. Of all those, I 
> really only see a bit of new topic related to native apps in 8.4, and 
> in actual fact it that sub-section should probably be reworded since 
> RFC6749 already establishes the public client type, which native apps 
> are and a reference would be more appropriate (which would reduce it 
> to just clarifying an old topic).
> What do you think of this analysis? Do you have any specific sections 
> or text you feel are better suited in the document body?  I will take 
> an action item to revise section 8.4.
> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman < 
> <>> wrote:
>     Hi,
>     I just had a question on best practice. In this document a large
>     part of the normative text is located under Security Considerations.
>     I had previously seen Security Considerations as things to think
>     about when implementing not so much as MUSTs and MUST NOTs.
>     I think it is okay to have it this way but it surprised me a bit
>     and wanted to ask if there is any best practice for the Security
>     Considerations section saying what type of information it should
>     include.
>     Best Regards
>     Samuel Erdtman
> _______________________________________________
> OAuth mailing list