Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

Dick Hardt <> Wed, 22 April 2020 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3BEF3A0DCB for <>; Wed, 22 Apr 2020 16:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CyUi8R1uyBU6 for <>; Wed, 22 Apr 2020 16:36:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36D553A0E61 for <>; Wed, 22 Apr 2020 16:36:22 -0700 (PDT)
Received: by with SMTP id w20so4323232ljj.0 for <>; Wed, 22 Apr 2020 16:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVy8w/osanS+ODuFpWCNRcxdx9w5n0z6l1q2/Ew0yUU=; b=WeTkn5PPqp6JxLE9qaADrrmfNlfFU6VlfJD62uaA9Gz8FGN23qDzasonEGgVQLs2bc I/vbKZrbMIYIh8sJCxCfynA9AsnsKbpLLYFVoM0cW/WnQ6ojxVCOk6vIXuzeVywsaLyM ymX3FJqThYDhe8iCukImnPPkMzBvIl3z6DlfoODJqZS+SqggYSD/KZj/fBQFqnTq1VLO yegn92uTMAgHPmpE/Qk6uoMYd+YpeLadyb2p//5+wVyQpe82AGU0/D5bW+Lhqw6NfJlN gYlT7UWFLgqtnCACP/60547kdkTNB/TTj0WB1kQydT9pshoK6M/DPw3FjfUrqVDO0EUF GSNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVy8w/osanS+ODuFpWCNRcxdx9w5n0z6l1q2/Ew0yUU=; b=l7jmLu+MU2F0ta9WYqFk0MpN7C1G354La+D6Obh/5ekxcdqjJJo4pz24ob8QgQsXPW bfa/Oa072W31nMbZAVbXPpXleLdVcIM2fEvs+os7xTN/D4WmgspLuqm4MU2FBuYmhDKm H85D7pBhY7rLpLqZwwuOgNLCLou5bnPqYRmO4t2WkW6rpq3wb4N2JHvbkxnblUJPk/kz 0EKqFTiJiYJADbYNHgoaW51bldH4eHbyUuWHvh7/dk4pHGohMmIWpvL7NyjINbrrxYw2 mP7KVPeFOpqSDGQRf7LJbuNXTbpMe4wwCJYyo14X4yWNDW8gNDsK4y6EHwew40q5vjKx KiUA==
X-Gm-Message-State: AGi0PuakAo/tGBwNtjr4RMDnxTZmRzt7mveZAsHzjFAnk1EGu94TnG6C JoxtQbelbx1fQDPsMZ9Blugm/p27J5/FgUs6cpLwcTlg
X-Google-Smtp-Source: APiQypKfHPuVpYucT4KC5DQqTPoORsWGz6pq3myrmqWLFZdaiZ7SbCBTDkMBBEr/dh62QhH/5rIUr7ySsWGq1MvY0IA=
X-Received: by 2002:a2e:86c6:: with SMTP id n6mr704658ljj.236.1587598580129; Wed, 22 Apr 2020 16:36:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Wed, 22 Apr 2020 16:35:53 -0700
Message-ID: <>
To: Brian Campbell <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="0000000000006a230405a3e999aa"
Archived-At: <>
Subject: Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Apr 2020 23:36:26 -0000

Brian: many, many thanks for all the feedback!

I did a quick skim of your comments, and will address the first and last

On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell <bcampbell=> wrote:

> Been working on this on and off for a while now (it's not exactly short at
> 80+ pages, various other priorities, etc.) but wanted to share my thoughts
> from an initial review of the OAuth 2.1 draft before the interim next week
> where it is on the agenda
> So for better or worse, here's that review:
> Abstract:
> "replaces and obsoletes the OAuth 2..0 Authorization Framework described
> in RFC 6749."
> I think "replaces" is probably unnecessary here and, to be pedantic, is
> arguably inaccurate because published RFCs don't ever go away or get
> replaced.

I took this language from RFC 6749:

 This specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.

And adapted it.

> Probably should also consider using the official "obsoletes" attribute
> marker too for 6749
> and probably also "updates"/"obsoletes" for others based on the scope of
> the rest of the document (not sure how this even works with a BCP or if you
> can or would want to update or obsolete a BCP) if this work proceeds. That
> scope could be better described in the abstract too as discussed somewhat
> in the thead
> and also the 1st paragraph of
> What is and isn't in scope is another larger question that I"m not even
> sure how to ask. What's included vs. what's referenced? Should this doc be
> incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda
> antithetical to what a BCP is supposed to be but it's also a bit hard to
> tell how much was used. I mean, what happens if/when the BCP is updated?
> And that kinda begs the question of if it should also incorporate parts of
> or even replace the browser based apps draft?

Our thinking was to include all the documents where the OAuth Security
Topics was obsoleting sections of documents so that it could stand on its
own, and roll up all the best practices.

If there are new best practices for OAuth 2.1, then that would be a new

> I guess that's a TBD circa page 68. There was talk about the device grant
> being in scope but I'm not seeing it (not saying it should or shouldn't be
> there but it was talked about). I dunno exactly but those are some scope
> questions that come to mind.
> Speaking of obsoleting, I do want to ensure that existing extensions and
> profiles of RFC 6749 that use legitimate extension points still present and
> unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm
> not sure how that should work in practice but want to be aware of it as/if
> this work progresses.

Perhaps have a section in the document listing all existing documents that
work fine with 2.1?


> "TBD"
> Given the potentially high visibility of an OAuth 2.1 effort, I think it'd
> be worthwhile to list organizational affiliations of individuals here in
> the acknowledgements along with their names. Something like what was done
> in the first part of
> This can help with visibility and justification of (sometimes not
> insignificant) time spent on the work by non-authors/editors.

 Sure. Are you ok with being added there?