Re: [OAUTH-WG] Review of draft-ietf-oauth-native-apps-05

William Denniss <> Tue, 01 November 2016 18:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F31A11296FA for <>; Tue, 1 Nov 2016 11:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 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=-1.497, SPF_PASS=-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 aQKo0kthk3tX for <>; Tue, 1 Nov 2016 11:02:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 419911296BA for <>; Tue, 1 Nov 2016 11:02:19 -0700 (PDT)
Received: by with SMTP id l124so48445702ywb.3 for <>; Tue, 01 Nov 2016 11:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yzbTdgMfQ3O6+1QL4qhNhSzAfhCUbi7pjof5Qktfrr4=; b=SUzaACJMorTb5GzW35PvHROC4EwD2ID5afFKevHiYfv+e5VbFN+IQG4cOoGRyQWYsU wPh0EudW9j5zG63V0zZptv8MCjRnOYzNrsidm8eKm3QGabpZFDL0b97fDGpBWjYEh7D5 /3bTfJ0DImtOUmvR0wzr7ZUKZLkDgHGCsF205gce9gOJ0Lwj6TbkUCxc29Mt0vvJOTyw NGgXPdhkbRZCsWxeS/iFmpIBLv0i+FlzB1SfJAEQnGg5PKeezRJ4HAxpRp1g9FwjdyBS CDDODL3x4pRPsltYOj3KkO5zy2uWCokZ9ckls5xByxgP1ZVhFoNxQ/QQRWDST8NEgLyh MuYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yzbTdgMfQ3O6+1QL4qhNhSzAfhCUbi7pjof5Qktfrr4=; b=JCmtTpqwbYavrHE/GwE5G/v43qzbl486G4v81aJ/NEk3hhdQ8saV9dUBosWsqiABWr 1EyLK+d988RC9zHkeOTHqAS0CjZygD9sQEcBZEM+pm+3zWqLborD1WkPnBeqzjcs4LfA mSt2+c/ecmS9QMkCpAJjjWLo+g/dIoT82r4nROYh0Dzw9nBgrglKFHO4gdW84b3tVWE4 +/211phLTnFykjD2JekhkODfW/5pR1k8mamvdCzIR+nywXOiKldZ4DecCXsZKJiJigCz Qwl+1tXq1frywBMctoiwS2y4dz/XUKmDg8ZFDUEWNWtnGJZuiocTZfJOlYH0TtRgrX0Z gAgA==
X-Gm-Message-State: ABUngvcBn1yLIRPq7T5lrcLvYMitqld5QNfVfagCInCxZl/+pRztAN8oTmIe8LiSM7X3bB9YjwigmzyP+n7k5zgR
X-Received: by with SMTP id g2mr30045305ywf.233.1478023338350; Tue, 01 Nov 2016 11:02:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Nov 2016 11:01:57 -0700 (PDT)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Tue, 01 Nov 2016 11:01:57 -0700
Message-ID: <>
To: Samuel Erdtman <>
Content-Type: multipart/alternative; boundary="94eb2c0357540dd4e605404120de"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-native-apps-05
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, 01 Nov 2016 18:02:21 -0000

Hi Samuel,

Thanks for your review! I've replied inline:

On Tue, Nov 1, 2016 at 9:41 AM, Samuel Erdtman <> wrote:

> 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.”
The browser is one external user-agent. Using an external agent is a MUST
to comply with this BCP, and the browser is the RECOMMENDED user agent.

> 7.1.1.  Custom URI Scheme Namespace Considerations
> “For example, an app that controls the domain name ""
>    can use "" 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.”
Good catch, thanks.

7.2.  App-claimed HTTPS URI Redirection
> If this is the recommended way to do it when possible maybe it should be
> first?

It's ideal in a security sense, but less broadly supported currently than
custom URI schemes. The order is roughly based on popularity.

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.”

Fixed in 06.

> 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.

I actually thought it was common, but I might be wrong. I'll wait and see
if others weigh in on this too.

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.

Can add a paragraph break.

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.

The former. The assumption is that other desktop apps may be able to
observe all local HTTP traffic on the loopback interface.

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.

It's there in section 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
        platform specific implementation details."

> 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.”

"Recommended" is used in normal sentence case here, but I can see how that
might be confusing, perhaps I should delete that word. Will think about
this section.

Incidentally, the idea for Appendix A was a non-normative checklist of
items for authorization servers to collect the core requirements of the
BCP, and give developers a quick way to evaluate authorization server

06 changes staged: