Re: [OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

William Denniss <> Sat, 03 June 2017 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E2FD12EADB for <>; Fri, 2 Jun 2017 17:30:22 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZD8yAe1T-CU for <>; Fri, 2 Jun 2017 17:30:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEC5112EAA6 for <>; Fri, 2 Jun 2017 17:30:18 -0700 (PDT)
Received: by with SMTP id m47so21290628iti.1 for <>; Fri, 02 Jun 2017 17:30:18 -0700 (PDT)
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=fOllomGy/TXSq8XTo5bQ+OxdAZ179x0LdNIuSQil8c4=; b=amuVfa3dxVTX77ccxzJlCbVsexOj46JFjSQlIOkHQKYV53nWma40JNajrNcEUX1mCb NohlCmSEsS1LMT7kFZNWHYDVM2kKoUlwtoyAuLTsp1mSQl18LVCJfOXxDjVd6U3LG5UE 7dIDzuQjDOvH5t9oiRqvyG9d489zKc3Q7HPVnMwQp2RC4Jn4G7uO0xoOok/EWFViEDvq VsZOqs8JP/U3pIldBj319PAHhHUYF4spdEZWkNLPDHDn+O8Oyjv/j2MMfydJAxC/jRAA 722BBOG9Z2GJ8sWNn9I1uBQanvG1zXGbPrFLLjfrL0G8btloARuyqHpUz53L25faMYEY ALOQ==
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=fOllomGy/TXSq8XTo5bQ+OxdAZ179x0LdNIuSQil8c4=; b=YkQVTshObWre5vcybyxJCMLZZdR6jU9DQSHLL0wfx273pxdURxpCUpd1+PqEV7ZelT 11QBnlqNJKbCfnXQDD67mQ63PcMcG6cQgVQ0v4OiT3/uzw1TEA1aUDRo1BsEm1vShWfv zjCjncmy8ttDiD/jxMYOIIsaXXFmjgrqPRiULL3lny77qBYs+6IVJWwHpMzsF1hA2nHN GdZK3HmbkusTChdBCMfBmiIJARwyCDT1x7rqVgbxKEZA7OlxwAo/oHA49DjZT3tQy6hY 0fNDRE/4YvllooDLmZkGyIXdPA5awi5yhbovOvEqoiaBsqXwvaXFSVNLxF0HOwD96WFA vdzg==
X-Gm-Message-State: AODbwcDGyML82fKmJF2FXRndNz2uPihmAm/rS2Dwy95nJKe4Yt3yqAoe Qn7MKBgxKds35aBRANTsVbU5B52GMj8U
X-Received: by with SMTP id 202mr2146363ity.2.1496449817818; Fri, 02 Jun 2017 17:30:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Jun 2017 17:29:57 -0700 (PDT)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Fri, 02 Jun 2017 17:29:57 -0700
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>,, Hannes Tschofenig <>,, "" <>
Content-Type: multipart/alternative; boundary="001a1144b174d147170551035f12"
Archived-At: <>
Subject: Re: [OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jun 2017 00:30:22 -0000

Thank you for your review. Changes to address your comments are staged
<> for

Replies inline:

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

One way to implement client registration on the server is to have a
public/public client type field, and an arbituary list of redirect URIs. So
more or less, yes, you can support it by echoing whatever redirect the
client registered. There are some specifics involved though, like the
loopback type needs to support a wildcard port for example.

In practice, many authorization servers place restrictions on the types of
URIs that can be registered for different platforms (for example, Google
and Microsoft both do this). I've also seen arbitrary restrictions in OSS
servers that limited the ability to use with native apps, so I felt it was
worth explicitly calling out. There are also different security
implications of each redirect URI type.

I've revised the text to:

        To fully support this best practice, authorization servers MUST
        at least the following three redirect URI options to native apps.
        apps MAY use whichever redirect option suits their needs best,
        into account platform specific implementation details.

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.

I've updated the text. The guarantee is to the authorization server that
performed the redirect.

> And I assume this SHOULD is directed to app authors?

Yes, updated.

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

I reworked this section to make the point that the HTTPS URIs are
indistinguishable so you'll need to use the client type from registration
to distinguish.

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


I re-worked this section so it flows a bit better and has less duplication,
hopefully I resolved this ambiguity.