[OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

Warren Parad <wparad@rhosys.ch> Thu, 30 July 2020 15:44 UTC

Return-Path: <wparad@rhosys.ch>
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 7614E3A09F3 for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 08:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch
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 RRyaA6-7sEIv for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 08:44:06 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 9EA973A09DC for <oauth@ietf.org>; Thu, 30 Jul 2020 08:44:06 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id y11so9735414qvl.4 for <oauth@ietf.org>; Thu, 30 Jul 2020 08:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:from:date:message-id:subject:to; bh=JHJQJkCvFqcrZAWCpGOb8UTo3d4OslU6WWxB0eGjdTA=; b=d0+1slN0H3ZwmLMn155K4lMQHAMgPCYiVXDD4pmAzdZUaJ55I5L6l/rQpLdCuKjVEd XIgHQlQVEgqnnYMu+7hm69ccE3t4q7AwvVKFwmQszyUo0mvfZDV/3ySJSaOkpWmXkwhU P+U+dOS1LHTvdLkQfuDFbbITYdSPE3yLSeQBc=
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=JHJQJkCvFqcrZAWCpGOb8UTo3d4OslU6WWxB0eGjdTA=; b=Ku6Tm7wLUlNyqH4PGf4yp7I26i+98cVebWs4G20DASb+z5Xm94C97AeBE9J7zurtpG okUdiPni8knRfT17kEqgeRQXkFbLZYUbG9WQk0PDBEG0ETDvI7BipTqwiimkG8p2tvMu 2ilL/3SROd/dGl3F2ECdphCeG1EsTcyD3BN80lKBTOj/je6HCzROhivfWMhRRcLsuzVD 8WtK6mmVmmSMR428UES5kKbIekelgNCsFxQIcI8j3DuByBQ2gIiIQjpUsDY5aocKOAuX wyBKyeJAPtyqy8teoEwtTtUhl8X7FBjdBEoN5SUkPmRtBeEB/BQSYjMocf2OLlHNABc0 lQxQ==
X-Gm-Message-State: AOAM530E2BhJh/luMo1ev6MAB84d/msq0lO7YIJDT6itQas9H865xe6r nweSmyFbaQD8lsbdjZdK64OEyK2fLg6NnC0PuHbEfM5d7M1Q
X-Google-Smtp-Source: ABdhPJw2LD/S4Ji8MB9bXQNAyREOymcAACMyrU+swJwY3k72x7ITyfKhD4WADNnqdeF6GsSsoQV3EWooigr3FB72wog=
X-Received: by 2002:a0c:d686:: with SMTP id k6mr3542667qvi.187.1596123841834; Thu, 30 Jul 2020 08:44:01 -0700 (PDT)
MIME-Version: 1.0
From: Warren Parad <wparad@rhosys.ch>
Date: Thu, 30 Jul 2020 17:43:51 +0200
Message-ID: <CAJot-L2yAaBAJ_q3KzPH3_U4ND0_TOXMiSjnLj_wz4YbPv5MuA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/related; boundary="0000000000009c6f8e05abaa8a0d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/f18vynrMXC4dj4tqck7SZIl4xp4>
Subject: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-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: Thu, 30 Jul 2020 15:44:09 -0000

https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens

It seems recently more and more common to pass the access_token to some RS
via a cookie, yet 7.2.1 says it defines two methods. I think we need some
RFC2119 <https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#RFC2119>
keywords
here, to suggest that either SHOULD use one of these two, or MUST. And then
optionally state whether or not we recommend or reject the use of cookies
as a place for access tokens. It's also possible that the language threw me
off, because would an access token in a cookie be a bearer token, but no
matter, if I'm having this thought, then surely others have it as well,
right?

[image: image.png]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.