IETF Logo Mail Archive

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Aaron Parecki <aaron@parecki.com> Tue, 20 November 2018 02:09 UTC

Return-Path: <aaron@parecki.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 7D7A6127333 for <oauth@ietfa.amsl.com>; Mon, 19 Nov 2018 18:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=parecki-com.20150623.gappssmtp.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 En4vIDK7YNJy for <oauth@ietfa.amsl.com>; Mon, 19 Nov 2018 18:09:18 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 B6850124BE5 for <oauth@ietf.org>; Mon, 19 Nov 2018 18:09:18 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id m1-v6so220881ioc.13 for <oauth@ietf.org>; Mon, 19 Nov 2018 18:09:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tRW99u+zGR7hNS6WFRX/qtdbi8Je5LaO2itau+Aqqtw=; b=YUUHr4/luiV0CQeTMeNvtueYtcHGA1HQMvSf2nRkmRt4QGfRsAvXfulgIRydouHuG+ FN1U/3VfQM0b0qfvaHQYFgpQMFUoPDTAJSRBnNSF8+SZ3dhszsVEC12f5E/uaRCpUTvS 4y0JmyW8VeUpunAKm++dJdZUy8+Jng+iVVCQNzVEC2mQaMzQXzz+V7ORdDT4yjWMr43H 0YoGrXuq+nvqkXK/12ZKPNl1afy73AkJPpIUcISQ8pZtZSCVZ2sHyUf89hHc02TOkoss nA6QAG89IiboT7EoSCEhgS29HLFyolQieFuTOFYi7odDttgsXil5Me9RSqAaDh238JJ6 WdjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tRW99u+zGR7hNS6WFRX/qtdbi8Je5LaO2itau+Aqqtw=; b=p9Oe804If6dKgsgeMJx8oZsVcAeRn5EEM3WGC8b6zxjx6yeFmckzA5f2hSc399Kqew KqL0epPVHg/aDzMj3577cJZrch6NYbWui2FkQDJxZUKXhbBRya4LEwmr99xUIu0COvoZ 0f/ENRse7yRsrbPnk7RuaJ4g1vlqsgeQ2TTvmSjnUErEPkLfL4anZu0zWlLJLOM3gnGs fxFmv/gTjnSnFPShTDxqZfGdA7VwUPSp9++35Ce+qxtD+oXyxPwaPCpxLpT4fk4+RL1k rN+Ns6+05KkZn0SaKv3YABL+dUWBdTt491vX3KN8JcemTcY5gQiIAdNM4s6dcvqh0X03 D1JA==
X-Gm-Message-State: AA+aEWZhZjgcKhTDlnQM9njmifSRcmeV/1lyOb1YkN0dsIHnUj4ONWF4 4GN3GcKXli7vna00tgnr8NswJ+ZA3/o=
X-Google-Smtp-Source: AFSGD/U6HWMIvauWieIbCNe/pl1IXbe7GYRyNiMfZTYR9qG5TWfp1y/YLw0mSTeQAcA+T25yYH9O0Q==
X-Received: by 2002:a6b:5116:: with SMTP id f22mr126054iob.28.1542679757760; Mon, 19 Nov 2018 18:09:17 -0800 (PST)
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com. [209.85.166.43]) by smtp.gmail.com with ESMTPSA id 186-v6sm14921750itf.11.2018.11.19.18.09.16 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 18:09:16 -0800 (PST)
Received: by mail-io1-f43.google.com with SMTP id w7so225712iom.12 for <oauth@ietf.org>; Mon, 19 Nov 2018 18:09:16 -0800 (PST)
X-Received: by 2002:a6b:8d8a:: with SMTP id p132mr105456iod.290.1542679755825; Mon, 19 Nov 2018 18:09:15 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <894C1893-8722-4005-8A33-AECADFD18024@authlete.com>
In-Reply-To: <894C1893-8722-4005-8A33-AECADFD18024@authlete.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Mon, 19 Nov 2018 18:09:03 -0800
X-Gmail-Original-Message-ID: <CAGBSGjotQpwoXR9vo1-dk4Wi+rVQ22Lj+UDBKU0-bNMJ3gd1MQ@mail.gmail.com>
Message-ID: <CAGBSGjotQpwoXR9vo1-dk4Wi+rVQ22Lj+UDBKU0-bNMJ3gd1MQ@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d92b97057b0f1e6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AOKmVqHntGouPqtfJgQR6gpql_0>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Nov 2018 02:09:21 -0000

On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <joseph@authlete.com> wrote:


> It may be worth slightly rewording 7.2 as it may encourage a growing
> misconception that all native apps must be public clients. With many
> devices now having embedded HSMs, we’ve seen increasing interest in mobile
> apps being dynamically (per-install) registered oauth2 private clients, and
> that model has a lot of advantages. (I’m not sure if we might see a similar
> model evolving for web apps.)
>

That's a great point, thanks. I've removed the reference to native apps
being public clients since it doesn't really add anything to this spec if I
have to caveat the description.

On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> > First of all the AS decides whether it issues refresh tokens or not.
> Having the ability does not mean the AS must do it. If you feel it’s safer
> to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats
> doc or in this proposed best practice doc). Not all end developers using
> these protocols fully understand the ramifications.
> @Aaron: I suggest this goes to the SPA BCP since this is client specific.


Thanks, I agree that this document should include some recommendations
around refresh token handling. Looking at the discussion in this thread, it
seems there are a few different strategies folks are taking. Since it seems
like there isn't a strong consensus, it sounds like this would be better
suited for the "Security Considerations" section, and to not make
MUST/SHOULD recommendations, but rather just point out the issues. Any
thoughts on that before I take a stab at writing something?

I've incorporated some of the other feedback here and published an updated
version:

https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01

Thanks for the feedback so far.

---
Aaron Parecki
https://aaronparecki.com

v2.23.0 | Report a Bug | By Email