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

William Denniss <> Tue, 21 February 2017 06:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16794129873 for <>; Mon, 20 Feb 2017 22:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DAdTV8pLcZXU for <>; Mon, 20 Feb 2017 22:44:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31477129861 for <>; Mon, 20 Feb 2017 22:44:49 -0800 (PST)
Received: by with SMTP id u188so38431578qkc.2 for <>; Mon, 20 Feb 2017 22:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nhHATXyJP317MVkMOlrxMwJPYriYIrbD82vR6ALs05Q=; b=KmeHsvmCHda//6EMkAr22q1sGuI//WI1AtMdoL/49bbk0/AHdabLbJUFJDSHZXb38D i2sYRGgCikzxtT0+JCgwxPdqDN+Bfzq9Xj1VILrLmlgcEudAPH0bQrFgY7xM5kFdjCN+ +fMJZgURPUwudCMOC8Zyw1yGt7drzjYFrZ4XG+Q0tnteVIM8DVf7MQc7ucQ3DWthf/ns 9+3m0yL5SF+0guShSn/NeTGwhCcIAegD2F21+FQKrLgeVu4mSnt/owpcxJ/D0dk/3W76 RRs35Il2YvdpUclrYtfNmwoRNv2s6igl+iSllpafMvEhyyD6sk3nwLkTu3Wa0A8U5gWb 4sMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nhHATXyJP317MVkMOlrxMwJPYriYIrbD82vR6ALs05Q=; b=IOYEmekXP2pHSTMOSmER7zoAPunogLhs4eJN0YLhui4MDSWtV0HColYmDC+MB6C5rS LY+VwThVR9Uezd9FoM5mXFk0A0V57jRW7ZJXLmI7XCrcrTq4ZxVXamYFInqGUAWHvF12 nf+pLGK4HfZZt/RNNKhdxBOYOf+uCMXsv3A4tUjQ3dxPJWWZ+ml4G7pcgGz2jkbKDZWl 8K+nz/N3u0+Lf9n/oDJqR5K7x9u5Spk7wXN86XpvfxH2D0Hmd90Rnb/OE8Kl3Yt9GYzI 7Gh7au0947aIMMifbfMjqSGLOkhMyOQj0JczqbA6dDgJYVW53A51KasnsP2ARqsh75/J yb5g==
X-Gm-Message-State: AMke39mSSEHGbjnieM3Sr+ADglaeVTugCLzYypSXjTl9lNjX1ZimntvnfNTITngfNQuVCRHwc0wie1XGy0nS0FC2
X-Received: by with SMTP id n67mr21402795qkd.286.1487659487903; Mon, 20 Feb 2017 22:44:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Feb 2017 22:44:27 -0800 (PST)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Mon, 20 Feb 2017 22:44:27 -0800
Message-ID: <>
To: Samuel Erdtman <>
Content-Type: multipart/alternative; boundary="94eb2c08849053238d054904b780"
Archived-At: <>
Cc: Hannes Tschofenig <>, "<>" <>
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 06:44:51 -0000

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

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

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