Re: [OAUTH-WG] AD Review of draft-ietf-oauth-par-07

Brian Campbell <> Fri, 14 May 2021 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 285023A3FE1 for <>; Fri, 14 May 2021 13:56:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 nALiYR-N12_c for <>; Fri, 14 May 2021 13:56:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB8BB3A3FE5 for <>; Fri, 14 May 2021 13:56:12 -0700 (PDT)
Received: by with SMTP id i22so197457lfl.10 for <>; Fri, 14 May 2021 13:56:12 -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=rsIB8vGpyWLFXGqwBpNOm8y+rzsWJSmZYT8Ti5DtIeE=; b=EhZIIaVqwM53rBHoop02DMAYLfOQmqCfGvtXa60buUJPZLq0co7l7Ifkr39JDtoVdS MvJTwUtTCUI6j4LYteBeMK4StjHRBbnzzp40X+UwLDXAQgHEmyVAfPQhLqdtQiTiJQ7t wAmM1ya8iCbUp7TpGIOgTUNSxARBZe+rgk8C1KuzG74/5eUhNdNWKzEbSIHhkJHeYy9a SZqtolTJP3avL9YYnNNrXcxh1riYhpMyjVCiqQhGIn/E3+NDNQcqb9jqKlcpnlas4ExX w8wgjf1hH7nbjSPOGopCNikmo7Hgnt8bf3Q6h15wYEt4rlFshcDGswqnJ1VijPEo02v4 RN2w==
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=rsIB8vGpyWLFXGqwBpNOm8y+rzsWJSmZYT8Ti5DtIeE=; b=IPkuWU+KpBL4e+b9AjK6sOkAMdkCpbSC/UqZMNp6hA6a5MTNuWqnahu+na8tjtWCKu rSgfcFPfbte+lX5BHYzeCxMocsDArO6q65lFVWrZkMMUzYalq9vJp20QrxmPRxd7u9r6 qM0evqRaw4HG4huUKCARjeN02Zc2ioffa7r9s1E3G2fZ7/ZD5dCE01WwpZJx4HHtttrp G5Ky2+VonjwTmlTDrdSMZ5Co2Nb6k72Mge5DN/z/xnpRhj2sM8oNOMFmEM+91YzEg9pp 7NkiT9UDHhu7ilfL7AOxX8I/LMhQk8buo38pTjzdIZEycsdgNVyxq7JN2AypCLU1MSJd ff3w==
X-Gm-Message-State: AOAM530nJBcAKAE1DKEgbAaGf+ha/UeQBwWqcDASXfxItp+DOcGi1Taf Cm8OqbeuQPZJQY+oN/EAW9A70Z37iwmH7xUcS03bLfepjU0erGZhsboRY4xJaX5bFwkx58vMBC5 ByIb+hXZY5O0hLA==
X-Google-Smtp-Source: ABdhPJyetoSsSfOrefdqCtic4QFY6W32t5sS/HI61wYnJmyMORldlhUuaqLL6sjZht2AjNv46k5v3PPGn6xZ17Wk0yE=
X-Received: by 2002:a19:6d0e:: with SMTP id i14mr32506581lfc.582.1621025769371; Fri, 14 May 2021 13:56:09 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 14 May 2021 14:55:43 -0600
Message-ID: <>
To: Roman Danyliw <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000027cf9b05c2507960"
Archived-At: <>
Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-par-07
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, 14 May 2021 20:56:17 -0000

Thanks for the review Roman! Responses from me are inline below. And I'll
endeavor to get a new draft published soon that addresses your feedback.

On Fri, May 14, 2021 at 1:17 PM Roman Danyliw <> wrote:

> Hi!
> I performed my AD review of draft-ietf-oauth-par-07.  Thanks for the
> effort to produce this document.  See my feedback below:
> ** Section 1.1.  Per the first POST example, please provide a bit more
> text to explain the presence of the Authorization header.

Makes sense and will do.

> ** Section 2.1.  Per step #1, "Authenticate the client in the same way as
> at the token endpoint." Would it be appropriate to cite Section 2.3.1 of
> RFC6749 as the reference for "the same way"?

I think a reference here would be good but Section 2.3 of RFC6749 is
probably more appropriate as any of the defined/supported client
authentication methods (e.g., RFC8705 or RFC7523) could be used. It's not
limited to client password/secret, which is what Section 2.3.1 of RFC6749
is about.

> ** Section 2.1. Typo.  s/the the/the/

Doh! Will fix.

> ** Section 2.2.  "The format of the "request_uri" value is at the
> discretion of the authorization server ...", it would be helpful to remind
> implementers (via reference) that the constraints of Section 10.10 of
> RFC6749 apply.
>    The authorization server MUST prevent attackers from guessing access
>    tokens, authorization codes, refresh tokens, resource owner
>    passwords, and client credentials.
>    The probability of an attacker guessing generated tokens (and other
>    credentials not intended for handling by end-users) MUST be less than
>    or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

I'll add that reference around the current text saying it has to be
"computationally infeasible to predict or guess a valid value".

> ** Section 2.2.  "The string representation of a UUID as a URN per
> [RFC4122] is also an option for authorization servers to construct
> "request_uri" values" suggests that a UUID could be used as the
> "cryptographically strong pseudorandom algorithm such that it is
> computationally infeasible to predict or guess a valid value" for the
> random part of the request_uri.  However, a few bits of the 128-bit UUID
> are in fact not random.  Hence, this UUID construct would seem to violate
> the guidance of Section 10.10 of RFC6749 noted above.  Likewise, the
> Section 10.2 of draft-ietf-oauth-jwsreq-34 referenced in Security
> Considerations also suggest 128-bits.

Good catch, if not a touch pedantic :)  Honestly, my thinking was that
creating UUIDs is made pretty easy in a lot of environments and that the
not-quite-128-bits from a UUID was probably good enough for the purpose.
But you are right and, under a strict reading, this amounts to the PAR
draft suggesting something that is in violation of a normative MUST in
RFC6749. I think the best path forward is that the sentence that suggests
UUIDs should just be removed.

> ** Section 2.4.  This section relaxes exact matching of the redirect_uri
> specified in the current text of the security BCP and OAuth 2.1.  Not
> relevant to this document, but would it make sense to acknowledge this
> relaxation in the BCP or caveat language about strict requirements in the
> v2.1 draft?

Yeah, it might make sense to do so perhaps along with some rationale or
explanation about the conditions that make relaxation acceptable.

> ** Section 6.  Typo. s/reqired/required/

Ugh. Will fix. And thanks.

> ** Section 7.5.  Per "Clients SHOULD make use of PKCE, a unique "state"
> parameter, or the OIDC "nonce" parameter" are good advice.  Can the text
> provide references to each of these.

Yup, I can add references for those.

> ** Section 8.  Wouldn't some of the privacy considerations of
> draft-ietf-oauth-jwsreq-34/Section 11 apply?

I read through that section again and honestly don't see anything that is
applicable or isn't already constrained or made irrelevant by the specifics
of the PAR draft. Please let me know if you think I'm overlooking something

> Roman
> _______________________________________________
> OAuth mailing list

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