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

Kathleen Moriarty <> Tue, 02 May 2017 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58E18128954 for <>; Tue, 2 May 2017 11:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YPyeRkk6MvsB for <>; Tue, 2 May 2017 11:37:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D357129C3F for <>; Tue, 2 May 2017 11:34:58 -0700 (PDT)
Received: by with SMTP id y4so60227582pge.0 for <>; Tue, 02 May 2017 11:34:58 -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=CfmWkdut5G4NUIe9tej1nwx3CUNJS2gGrGT4xJD2jqQ=; b=EEGJuWOqxYFOYYEFbeeIH+4CIfDdB3EnpIroDdrw07fXLo0e0bOf1yjFHHuUbMedHS TCasAewSa7XU6D1f0ctQFzO0/jrGc4uzsWUNGNeSXsl7IVVB5qSzALmtYf4m6cXLhE55 JWQsqsNfUYLNB1vkfMQkr5plPK2WZGG+F23WHuntaAEmZup7UJ60jBl/zjkbetTRmXxz 2V9lUNGNS/ObUrbUsGGj9TUgJfJS4SrAYSTh/8bIkG11G8Hw+miYDGKJW2dQ1NXOwTl3 BlzmOnKLpBqr6RyJC1CG+Q6DyvtoYMYIccxGU6CAdbS2P/gTipkimJcohAmQioIQkpAA Do3A==
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=CfmWkdut5G4NUIe9tej1nwx3CUNJS2gGrGT4xJD2jqQ=; b=JTylbUnavvehJpWr4XiSDFjr6myHDLol903FqprernGVPsg6tfm5w+XUznbcUk0HqF pbj5mhl7s619uObR7qMLisQjxd5SpPQkP+Q/+JPtHPBsHf0ihGvXz7K9W+IhtHWIoejM tizaYMrZSCd5E1W03edDxdSTdNNTxAI0Zhzgqtnip7kp6DQfASTFgW1uN2RW65YSSy2t NfQfU+mb5jfWBXyidhHE2G1UGhm8I/vNgrYEC1mWPhfr77T1/jN7xLc7YvrKCFcen87w WlorO7qxxbN3ffcESRxvFnWyHXEbJ52y2hj9OeOZVCv06Rrjp1UDyqsxd8O6qkQrR4J+ wL6Q==
X-Gm-Message-State: AN3rC/6oIk2nzrJ7wIi5tf4Nk89K8t0QWERkt0COvg0Zrptmd8MqIFSy jMh8bABcl6eV/4eMM4iwoGnSqAyPwA==
X-Received: by with SMTP id b8mr43793110pll.107.1493750097862; Tue, 02 May 2017 11:34:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 May 2017 11:34:17 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Kathleen Moriarty <>
Date: Tue, 02 May 2017 14:34:17 -0400
Message-ID: <>
To: William Denniss <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 02 May 2017 18:37:45 -0000

Hi William,

Thank you for making the updates.  Just a few notes inline and I'll
kick off IETF last call.

On Wed, Apr 26, 2017 at 5:50 PM, William Denniss <> wrote:
> 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.

Great, thank you.
>> 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.

Sounds good, thank you!

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

I missed that, but if it's defined, then you are covered.  Thanks.

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

Perfect, thanks.  The point in asking was just for other reviews that
will follow.

>> 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/
Thank you.
> Fixed.
> Best,
> William
>> --
>> Best regards,
>> Kathleen
>> _______________________________________________
>> OAuth mailing list


Best regards,