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

Brian Campbell <> Fri, 24 April 2020 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E0D43A0AD3 for <>; Fri, 24 Apr 2020 13:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lUFPMUkCiXkv for <>; Fri, 24 Apr 2020 13:36:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92C623A0AD1 for <>; Fri, 24 Apr 2020 13:36:52 -0700 (PDT)
Received: by with SMTP id n6so11313425ljg.12 for <>; Fri, 24 Apr 2020 13:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lG3On5XVOoJefWXnPu2ZH6/2yWim+ASw0LJA3WmTTHM=; b=J9X13ok9gG6EIZ8S5eooe0l4j5g5smKvkbbAqe1rXzgsh/LUgdMT7ssp5NStDgR/KG DUpzE81s/+JrbjjtwWEtKNKHI9LnAzgaRJ/qdDQOIdHB1Mt3eFgwwpOOhXaVYulOJijx d+LH+Ngnr4K09nyifedXLaGJ/nsr7IoR9JdzhESDXUcsKIMs7FQCWy+ueq65pUqyyeoP CjBJqALiUACgM0uLD/v+9kIr8lebkOb054kOW2AS8S/etmtdHba+/r/zm0vdRMfDP7pd UcsdeoMxAQs5fCmT2pPGbBmBh+vYKvzSamgJzL8sd07we365eCRhD4jcowrRqhBP+fEC lM2g==
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=lG3On5XVOoJefWXnPu2ZH6/2yWim+ASw0LJA3WmTTHM=; b=R7/U+PoTtR3tnas8zH9t54vGpBYqpsUfBJ1WAs/zr8x3JOzZok8HoGsm68vTDcWH7p t7gzFU50yH3p99We8kmyKAg/JZ4xag3qvhb3TcVrS0MpV5wtdLrgf+6nOGDErQuzjTBa NaNX8Bahxg2wyFhBQiYQsMhTzEuMfoMReim0VPQBhX8CebbDfgtmCGm4TZH72VIxWpeo S3aRKbDqLEFxrn2Ut0nYNcO5Dqj2qg1vr3NGScbivYztmFqNhMa08mhEJxy323BjMZCx J0bH+GvvWuTPltEgA5Hw80fR/EP5r/ZQkeVWNoZ39xH02OZeU2g1Wk2Gh6jbTGwN6bsi OyHg==
X-Gm-Message-State: AGi0PuZR8mbDBy3YhhCNBZqvHIY8HoaTZfAK6nSphKIOm8E5OyH4Gq80 C8GvJMDFNqizhhQeoJlJy7sayIA8wHM/5k0qYJV0h5IJO8clqlWi+Gdmhfd5f79KNIAnIiklCyn 6uA0lxrwsU9x+Qw==
X-Google-Smtp-Source: APiQypJ0ixB+eM/rGIoqFRFIFAp/t2Kt6NVraoQjYt3ypfqybcuplboHRFkBAx6wJozY3LH37IOMze6tfWgLBpc5qVU=
X-Received: by 2002:a05:651c:505:: with SMTP id o5mr449321ljp.0.1587760610764; Fri, 24 Apr 2020 13:36:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 24 Apr 2020 14:36:24 -0600
Message-ID: <>
To: Dick Hardt <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000031816905a40f5365"
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: Fri, 24 Apr 2020 20:36:56 -0000

On Wed, Apr 22, 2020 at 5:36 PM Dick Hardt <> wrote:

> Brian: many, many thanks for all the feedback!

You are welcome. I won't lie - it was not a quick exercise :)

> I did a quick skim of your comments, and will address the first and last
> ones.
> 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.

Well then, I guess there's precedent for it. To me, it doesn't seem quite
right. But I won't argue further with precedent.

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
> BCP..

Okay, thanks for the explanation. I think that generally makes sense.

I was thinking more about the other direction like what it would mean for
OAuth 2.1 to update or obsolete the existing BCP 212. But maybe that's not
even an issue.

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?

I'm honestly not sure if anything is needed or not. But I do want to try
and ensure that such a perception problem doesn't arise.

Perhaps have a small section that says more or less what I'd said above -
that existing extensions and profiles of RFC 6749 that use legitimate
extension points still present and unchanged in OAuth 2.1 are still okay as
they are now? And include a not-meant-to-be exhaustive list of such
documents as examples thereof.

> <snip>
>> "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?

Yes, thank you. That was sort of implicit in my suggestion but perhaps I
should have been explicit.

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._