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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 25 April 2017 01:47 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 901BC1319A3 for <oauth@ietfa.amsl.com>; Mon, 24 Apr 2017 18:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: 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 BUUxQIFWwFJh for <oauth@ietfa.amsl.com>; Mon, 24 Apr 2017 18:47:47 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 2DDB11319A2 for <oauth@ietf.org>; Mon, 24 Apr 2017 18:47:47 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id a188so19743129pfa.0 for <oauth@ietf.org>; Mon, 24 Apr 2017 18:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oY1yEwrmW3jg9K9LdvKtPNDwazLzoaeT4KoM5ufo8vI=; b=eg/qs+ySvNiehX7hgdW2Mv8SvCBvtJ20wY+4oLPHPtvGN9rvawwIkC+MtxeLBgcA9X ZNYRNHae7LzgDi+0+29Z7O3zsXZMnjlTlifnhLm/SZ0E2/b4lG/FN+OwqDzfuCfZeymz zk1K3XQMBf/2FU6t5RQOajFcFtD3M7vAoyHxI82f8U54p6srmq7yp57GobZ1FD69S6Hb oa+2MR31HLpwckfD5dcbgsH3+CGT5koRBlaxM3ZDwLDGX1y6WrHa4O0a6cGRLgiQMpu0 kALSVMVi1EMyyjrYZN1KDYdu5wY6FZEDqQ0Cu0v68EuYRxEqDFeaOtknjMKLH0m1mvwx ZRxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oY1yEwrmW3jg9K9LdvKtPNDwazLzoaeT4KoM5ufo8vI=; b=Vrx1DuU3gP063m8qKwRc8kNe0/jHAPxa6/BgAQD5GIfLTWYUmGU7t8GwFebuaxpuEi 1n32LUOhsu++08xbiZ4M+HJ9LkybQ+6O2i+5E9U8OJswpkrToYkFMYfO6UQJSCNjZV98 371Yftpydd1lNNb9RAkZE5/+UirA1g2loHVpAGAgHxOhDLlFP1STeTE6GoGFxfsGLrFE i+wD8+IpuK1zT19qxD6ULC9TznXH3xdgZFKHBCXTI2HhiUJ7ntV0/sHZj1S+aukwN6o7 XtcR2mU9P2l4uvwc3nFh7RHGA2OsSdjM0Ghi9yOphKifsbDSGWlp0kRJVrBdchWVFifa 75Dg==
X-Gm-Message-State: AN3rC/7aaiZzosIrGklJ0D2+grCxcocfaucaHqqjfVgTd4fdEVvCJ9l8 d2Ic52d2Ja9rWDA3g108n1PWnYV9oQLz
X-Received: by 10.98.92.2 with SMTP id q2mr6508523pfb.244.1493084866602; Mon, 24 Apr 2017 18:47:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.185.143 with HTTP; Mon, 24 Apr 2017 18:47:05 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 24 Apr 2017 21:47:05 -0400
Message-ID: <CAHbuEH5Pa2-K7Y+w0neyVOLBxn4XfZifiNfc6rvgAVN5nBZGpw@mail.gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hCxEBXEKjr6vKhDHUWNYZWOxNXQ>
Subject: [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: Tue, 25 Apr 2017 01:47:48 -0000

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.

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.

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.


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.

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.

Section 8.11
s/uri/URI/


-- 

Best regards,
Kathleen