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

Aaron Parecki <aaron@parecki.com> Fri, 17 January 2025 22:58 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 1D3C9C1E7242 for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2025 14:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMAMngHe89Di for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2025 14:58:51 -0800 (PST)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DA8C1F58A7 for <oauth@ietf.org>; Fri, 17 Jan 2025 14:58:51 -0800 (PST)
Received: by mail-ua1-x931.google.com with SMTP id a1e0cc1a2514c-85c4b4cf73aso576171241.2 for <oauth@ietf.org>; Fri, 17 Jan 2025 14:58:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; t=1737154729; x=1737759529; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DaXDaown+gtvoFwgqC0CDZZUSs9GaM6lJSezMphi7L4=; b=B7Akqd+1EI3Jd+ojxj4+Wy8PMh9ERs6imjoYpg9Q1bYJd+s28WP7QIMYIdwzlfm5f0 3UJAJtfH68szALa7OiNs6hrzbdAXE3FH2KK2SYotm1JqVXAf7ax0HIPlGOpGBMVRfuim mH7srne4rI8v+5r5EHorV61RSdEUAYbqjITAT6hVCjRFiG6nvzQN7gDod48uZeFor/tW 5+97Bo9RLFZN2K1L/NlVmCU77Lozb6yX56OA23CWegPh6bBrsci3+OBDN9AZbwICWit0 ISjpj2FB9zBo9wFBgqHArost/+vAd8dL5rFCkSmYjJN37vOgpFtV77KjB23ou8UG8XHK tosQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737154729; x=1737759529; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DaXDaown+gtvoFwgqC0CDZZUSs9GaM6lJSezMphi7L4=; b=dp0opsZWoAxBeoXQW/5DzirWqHI+3x/dcbwI/7Mct2GQLSloQEK9norbAM3G7krO7T EUFONYHBa54J0xGAMyqCiadllYyGBbSB0axHTAkrD7o1b8NF7uPP2i7LrAOrK3B6vfHv rBoVjn6H+JI2MXili2SuqT+1fxrGK55T9EvTQRFzMpAS9sSzrk8IDuz/lXJFwIQvL9iw aNkdsgqvS6yy46ekfhfbUeBVn8hnUfhcA02lMznprGhm4YpZEYDv9Vf6GG7u6Mh5Vs84 o7zUVNdvsrCkKbA/oSK99DCP0qSM0BXzdJbJCejVYJZ1t1jy68asHlFcAA8LuNZPnJDX W2Og==
X-Gm-Message-State: AOJu0YxvNgdI8VhLL7we++pVBlPBluYjOm48sKrxDYIRjflxR3YjcaEJ wA2E9twFDA2dBVUPc7dUAWjFZWybEiMFSFlh406pZ42/BGpNUOSQR1UpWB8dGj+Ztsubi4NMIfM =
X-Gm-Gg: ASbGncuwMr4qQGe6NZPdOjnAFWL0o/RChLS4rHQS0B4UnN4zni02qw3LTYtrV1NPVpP HW9WHp0G1o3zedBbN1+NB+eDc8pSrXBFe8jsUga1mAM9UVcW51aT0yewGQCHacGm25W5Xx+CQwc GDySenSEumscvWpaGxVGkEt/YU+GsYa++9MOLBliwF8w53siUF5Ddg6Bz5uh2Lxg+v3hfNFGzLZ cev06oSLWqwVEQ5M0oMZEfM/CpEopD5UJN3d2fZFpDskMTtDrdEEc8QdJyJ7BrGnWsAv4vz2xhd Ejbj2pW9ENIH1XNTBUE=
X-Google-Smtp-Source: AGHT+IF5P2gxgtAPbdCD522fiLghGw3D6dkPSj+2J1gwTftDANoE5jGFF4s27DRGtKso3CNqMVJW3w==
X-Received: by 2002:a05:6102:418e:b0:4b2:4877:30bd with SMTP id ada2fe7eead31-4b690bfba7cmr4820688137.12.1737154729153; Fri, 17 Jan 2025 14:58:49 -0800 (PST)
Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com. [209.85.221.170]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-4b68a208620sm661906137.10.2025.01.17.14.58.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jan 2025 14:58:48 -0800 (PST)
Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-5160f80e652so649450e0c.2; Fri, 17 Jan 2025 14:58:48 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCU1yeEkRWhRodnHNzEDZss/OwSEKe78VseXNff4SeqOmXThL6UXxrVTFZe2GN7qtqwWmI26D8dWfBQ6MKT4@ietf.org, AJvYcCU64L6MMiwipP7jKAlWyETPSeaXKX9FTP8VCB32pBrWnEsy4NwKsPWSFNPCkENNu4Y/BcvjClUQFmgw+LpmUIgMAiXCbCFYVjZlA3eo3PLTbjQsrKl6yZFvkIzn@ietf.org
X-Received: by 2002:a05:6122:488e:b0:518:6286:87a4 with SMTP id 71dfb90a1353d-51d595af946mr5497953e0c.4.1737154727985; Fri, 17 Jan 2025 14:58:47 -0800 (PST)
MIME-Version: 1.0
References: <CAGgd1OcTGfQ38Yf7FJ+g8t70UbOVw-LLco28P3t1=J5Mc5j_+A@mail.gmail.com>
In-Reply-To: <CAGgd1OcTGfQ38Yf7FJ+g8t70UbOVw-LLco28P3t1=J5Mc5j_+A@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 17 Jan 2025 14:58:37 -0800
X-Gmail-Original-Message-ID: <CAGBSGjqfnCrEa5q03szWs4UUmv8hynzxUcJwvnOc_RdND2Hf_g@mail.gmail.com>
X-Gm-Features: AbW1kvbqCp7ttWv4VXnZZaQkwwsepvnUJv03h3QTNZhHO5GGsKrXKq_DKN0c9HM
Message-ID: <CAGBSGjqfnCrEa5q03szWs4UUmv8hynzxUcJwvnOc_RdND2Hf_g@mail.gmail.com>
To: Deb Cooley <debcooley1@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007b520f062beeda29"
Message-ID-Hash: BRORE2IHVDOADX2YXIKWAP4C7W4UM3OD
X-Message-ID-Hash: BRORE2IHVDOADX2YXIKWAP4C7W4UM3OD
X-MailFrom: aaron@parecki.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>, draft-ietf-oauth-browser-based-apps.authors@ietf.org, oauth-chairs@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: draft-oauth-browser-based-apps
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JMpMU-seAMSpMUs3-qIkIeCY3mg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Thanks for the review. We've just published draft 22 addressing this
feedback.

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-22.html

Comments are inline:

> General:  There are more than a couple of Normative references that are
pointing to 'living documents'.  From my reading of the draft these
include:  Cookie Prefixes, Fetch, Web-messaging, service-workers,
webstorage. If at all possible, we need to find a way to specify a
particular version via commit, snapshot, archive to make an immutable
version.  Or find a way to make them Informative.  Basically this draft
will be an RFC - immutable, yet a few of the Normative references are
changeable.

I was able to find links to snapshots of all the living documents
referenced. All references now link to the stable URL versions.

> BCP 14 boilerplate:  idnits (a little blue button '! Nits' on the line
above the text of the draft on the main datatracker page). is throwing
errors on the BCP14 boilerplate.  Ideally, I'd like these fixed before
moving this along (it just eliminates problems down the road).

It looks like these nits fall into a few categories:

* Date issue (will be fixed on publication of a new version)
* Wrong RFC 2219 boilerplate (fixed)
* Non-RFC references (may still be nits, but now reference stable versions)

> Section 6.1.3.2, para 4: '...the BFF SHOULD encrypt its cookie contents.'
Why not a MUST?  Under what circumstances would it be reasonable to ignore
this SHOULD?

We added a sentence following this to clarify that the difference of
encrypting the cookie contents doesn't affect the security properties of
the BFF pattern.

> Section 6.1.3.2, last para:  Add this to the (Informative) references.

Done

> Section 6.3.4.2.2, first para:  Add 'CrytoKeyPair' to the (Informative)
references.

Done

> Section 7.4, first para, last sentence:  Nit:  'This restrictions' should
either be 'these restrictions' or 'this restriction'.

Done

> Section 11:  RFC6819 is a normative reference, but it is Informational.
We need to call that out in the IETF Last Call, and I have to approve the
downref (which I will do).

Moved this to an informative reference


On Thu, Jan 16, 2025 at 6:27 AM Deb Cooley <debcooley1@gmail.com> wrote:

> Here are the comments on my AD review of this draft.  Most of them will be
> easy to fix, except for the normative references to changeable standards:
>
> General:  There are more than a couple of Normative references that are
> pointing to 'living documents'.  From my reading of the draft these
> include:  Cookie Prefixes, Fetch, Web-messaging, service-workers,
> webstorage. If at all possible, we need to find a way to specify a
> particular version via commit, snapshot, archive to make an immutable
> version.  Or find a way to make them Informative.  Basically this draft
> will be an RFC - immutable, yet a few of the Normative references are
> changeable.
>
> BCP 14 boilerplate:  idnits (a little blue button '! Nits' on the line
> above the text of the draft on the main datatracker page). is throwing
> errors on the BCP14 boilerplate.  Ideally, I'd like these fixed before
> moving this along (it just eliminates problems down the road).
>
> Section 6.1.3.2, para 4: '...the BFF SHOULD encrypt its cookie contents.'
> Why not a MUST?  Under what circumstances would it be reasonable to ignore
> this SHOULD?
>
> Section 6.1.3.2, last para:  Add this to the (Informative) references.
>
> Section 6.3.4.2.2, first para:  Add 'CrytoKeyPair' to the (Informative)
> references.
>
> Section 7.4, first para, last sentence:  Nit:  'This restrictions' should
> either be 'these restrictions' or 'this restriction'.
>
> Section 11:  RFC6819 is a normative reference, but it is Informational.
> We need to call that out in the IETF Last Call, and I have to approve the
> downref (which I will do).
>
> Deb
> Sec AD for oauth
>