Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 18 May 2017 18:14 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EA7127599 for <oauth@ietfa.amsl.com>; Thu, 18 May 2017 11:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx-Pz5qgHz2d for <oauth@ietfa.amsl.com>; Thu, 18 May 2017 11:14:16 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AABD12EB28 for <oauth@ietf.org>; Thu, 18 May 2017 11:08:48 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id u28so26393293pgn.1 for <oauth@ietf.org>; Thu, 18 May 2017 11:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BRUVpZLUJEbNWNqIZaA6GIUCHa2SAn9I1LH5iTZUCWM=; b=lOmCC+/e3XINuIueaWyHUzN11kNi9v1ixCP3q5/BQz1umLCa735AHuRDvsXeRcnYA7 sQGBCiikr9aQnFSXBQlxZZ/hexg1Baol/CYUjZfh2hVo2yLOx+2b/HH5Hd3ZaIW0fNmb rx2TSIxxmT+i81WbBXk76Z5bSen2wskqFMcRtpWAdCRT3XsIGi+OuKRISksZmkF2vCZB XrejUdP1tn4+KxTh9cWusJoLgbpSdsQKHGpVi8DLlOljOJNXY9PN2KZ4m6b/2wBxa+W5 qkjGj6xXir5nVyGrYvC74ZtJmR4Y1++QTjuvS5PriwTdvqIkSaCMHNp2mQyeJlLKVyNi vdAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BRUVpZLUJEbNWNqIZaA6GIUCHa2SAn9I1LH5iTZUCWM=; b=VXdFic5gcaGFmDGecFawUPVVjAvIfEmtU0qpgYLDb/gsjNJd7vCn0pClL0l2YOSW5p AbMPmG3luuDMtBGSI73VT9Ill7GM2ThjvR9IjP9+0/HAGSLffSRFQnWD5K3ZACZLoGkR K3FOr/7mLt2kNfwCz7SeLJfcPW3/9gEuVSjF+4Yw7gqIc68bnHAif2/NJx30/i0sC3yz qpY2h/J9D42Y8q9c100cSb5bRWR/9m9mH5U2LCLI/nNblttTpGRmvZpP5eFtMLBCYHTj 9QUD9spChu5kHEFDzIMuqVqiGdMtCM8rxoNXiVlDCgUoaRfQydFBH7phmzFrAkzNYw68 xwMQ==
X-Gm-Message-State: AODbwcC3xy3j4V015AYUkl1VQTAtxCE3v7MOq6U1G1wWbmdU3AJickbv uzlRpZ9Cj2ozY53Eq6J3gWR4DNy78g==
X-Received: by 10.99.96.3 with SMTP id u3mr5747603pgb.69.1495130927792; Thu, 18 May 2017 11:08:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Thu, 18 May 2017 11:08:07 -0700 (PDT)
In-Reply-To: <CAHbuEH4Hn-z1d2xssGLGzTY-8FYkwZch=Cf53ch51H4wg6aseQ@mail.gmail.com>
References: <CAHbuEH5Pa2-K7Y+w0neyVOLBxn4XfZifiNfc6rvgAVN5nBZGpw@mail.gmail.com> <CAAP42hCC2w1NXKnx8BX5dGY5jec_XPt39_2=Pi=-0HGznOZROg@mail.gmail.com> <CAHbuEH4Hn-z1d2xssGLGzTY-8FYkwZch=Cf53ch51H4wg6aseQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 18 May 2017 14:08:07 -0400
Message-ID: <CAHbuEH7Zn9tGNS57Z4rYLFqPqbQuXf9z7B0n2voUsFawHVNZFw@mail.gmail.com>
To: William Denniss <wdenniss@google.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5qw8N2nGBQBn_8EojFFBJka8Xng>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 May 2017 18:14:18 -0000
Hi, Will there be a new document posted today/tomorrow to address last call comments/the GenART review? I'd like to add the ballot for the IESG review and telechat next week, , but it would be best on the updated draft to avoid duplicate comments. Thank you, Kathleen On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote: > 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 <wdenniss@google.com> wrote: >> Thank you for your review Kathleen. >> >> Version 10 which addresses your comments is out: >> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 >> >> Replies inline: >> >> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty >> <kathleen.moriarty.ietf@gmail.com> 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 https://tools.ietf.org/html/rfc5226#section-6.1. >> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen
- [OAUTH-WG] AD review of draft-ietf-oauth-native-a… Kathleen Moriarty
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… John Bradley
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… Kathleen Moriarty
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… William Denniss
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… Kathleen Moriarty
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… Kathleen Moriarty
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… John Bradley
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-nati… Adrian Imach