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

William Denniss <> Wed, 26 April 2017 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E528128B91 for <>; Wed, 26 Apr 2017 14:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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] 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 Xgk6cw25ox-X for <>; Wed, 26 Apr 2017 14:51:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B41BB12709D for <>; Wed, 26 Apr 2017 14:51:17 -0700 (PDT)
Received: by with SMTP id r16so11655710ioi.2 for <>; Wed, 26 Apr 2017 14:51:17 -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=RNaKdhp4tjMUJv71ArKpAYf4EowaJM18DXFyvBHdqNQ=; b=dXLccAOZnHG4VQQZ/vnFPCw1UxQfed/xilcuOsZjPbEFI/jX8cFvHoODR8HnaWtxgg W2g3vjaizUNl8AyRZ5Ocy12SmghNXpvWDmdCZJoRGA/uVvZFXiAlgwujZGLlbgiSAvel 6ao981qx9xwV2HtFWM4PZA2yO4uqhpPYquEvZcDgAKb1Y+TIQrdhjK1wzcPH9lPtOnAY PcQtLryiGrnmB2dRW+frUm0KSgD/VA00dTA9y+kwvKyRJIjHnjofJ8oVYhVrPo0IyYrX Uhdtnz7TjSStmS2pdf/+wunOYnMMxUtqLaCfVHVJ2R40DOwsA5bl1OBuQRcg+K2CKuMR CScQ==
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=RNaKdhp4tjMUJv71ArKpAYf4EowaJM18DXFyvBHdqNQ=; b=LP/F0lt9AGCvIc8x9hxr2VjOF/fy/IdlFBbT/P8HNBQfE1NLmmfw7VlHFn2EHYX5GP MNO9RQxFLiq8d4eH431AG12N6pPpy9o1Io1/ran2A0U0vUj20oH9xnZpqn5BhF4OTOfX jXuTE0pQsdn2Vf+x2JfDixm2Lx13v+3bCU/9o5WvnOBFuxBxGngErLMOxp8q0xUVVCsV m8pxt2GdQV3GMvF4gKZNQLmWie5yX2MU4mVySYsidFb0fKhEGXoYV74yyPZZDe/q7LNO 24y51HdD0tPGUX2P2xhzvyAWeTkkBdwBSHTThFndFv0H2RwsPsYnj0VL3GQrl2SvxJJ3 x9Pw==
X-Gm-Message-State: AN3rC/58zbWV7D7FVnk7r9KbywwnPBVFRn4NisRiRA0n1/IkloOJvAyq swSR/i/MkFmQ4RdXq4/8Wd27DX3oSZzJ
X-Received: by with SMTP id f19mr1985465ioi.53.1493243476629; Wed, 26 Apr 2017 14:51:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Apr 2017 14:50:56 -0700 (PDT)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Wed, 26 Apr 2017 14:50:56 -0700
Message-ID: <>
To: Kathleen Moriarty <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a113f9bb6fd7008054e18d6b2"
Archived-At: <>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps
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: Wed, 26 Apr 2017 21:51:19 -0000

Thank you for your review Kathleen.

Version 10 which addresses your comments is out:

Replies inline:

On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty <> wrote:

> Hello,
> Thanks for taking the time to document this best practice and the
> implementations in the appendix. I have one comment and a few nits.
> Security Considerations:
> I think it would go a long way to organize these as ones that apply to
> this best practice and ones (8.1 and the example in 8.2) about
> alternate solutions.  This could also be done through some added text,
> but making this clear would be helpful.  Maybe moving 8.1 and 8.2
> until after the rest of the sections would be enough and then clearly
> state the intent of this text.

Good idea, I think that will help with the readability a lot. I have moved
the "Embedded User-Agent" section to the end, and clarified the purpose.

The reason it's included at all, is that OAuth itself documents two ways to
do native OAuth. This document recommends only one of those ways, and I
thought that detailing why the other way is no longer best-practice would
be helpful to readers.

IANA Section:
> Just a note - you might get some questions about this, but i do think
> it's fine to leave that text, although unnecessary.
I think I may have mis-read
There is an example of a document that has no IANA actions but still
provides a justification for why that is the case, but in that example it
uses a non-IANA registry unlike this BCP.

In our case, we are definitely operating in an IANA-controlled namespace,
but using a private section of the namespace designed for that purpose.
The intent was to point out that we are following IANA guidelines
correctly.  Happy to remove it (or indicate that it should be removed
during publication) if it seems superfluous.

For now, in the latest update I have clearly stated "This document has no
IANA actions.", but retained the discussion.

> Nits:
> Section 5, punctuation
> OLD:
>    By applying the same principles from the web to native apps, we gain
>    benefits seen on the web like the usability of a single sign-on
>    session, and the security of a separate authentication context.
> NEW:
>    By applying the same principles from the web to native apps, we gain
>    benefits seen on the web, like the usability of a single sign-on
>    session and the security of a separate authentication context.


> The document has text that says 'native app' in some places and 'app'
> in others, I assume these are used interchangeably?  It seems that
> they are used interchangeably.

Yes, they are. In the definition section, "app" is defined as "shorthand
for native app". Is that OK, or should I revise?

> Really nitty:
> Section 7.2,
> Since you are still in the example, did you mean URL in the following:
> Such claimed HTTPS URIs can be used as OAuth redirect URIs.
> Such claimed HTTPS URLs can be used as OAuth redirect URIs.

I have migrated to use URI exclusively, other than 2 references to URL
where I'm referring to platform-specific naming / colloquialisms.

I also changed instances of "custom URI scheme" to "private-use URI
scheme", the latter being the terminology used by RFC7595.

And again in the last paragraph of this section.
> I'm only asking since you specify URL earlier in this section, so you
> were more specific for the example and then drop back to URI (which is
> correct, but wondering if you wanted to continue at the same level of
> specificity or if there was a reason to just say URI here.

I believe this is addressed now.

Section 8.11
> s/uri/URI/


> --
> Best regards,
> Kathleen
> _______________________________________________
> OAuth mailing list