Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt

Brian Campbell <> Tue, 11 August 2020 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 384BC3A0D3E for <>; Tue, 11 Aug 2020 14:55:37 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uu1AxLw5YNe3 for <>; Tue, 11 Aug 2020 14:55:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0139C3A0BCF for <>; Tue, 11 Aug 2020 14:55:33 -0700 (PDT)
Received: by with SMTP id w14so15240640ljj.4 for <>; Tue, 11 Aug 2020 14:55:33 -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=uqkekHKEwvK+nMiW2wYWljockfxGIZlMBY61B4YWWCY=; b=BUR8ebmi2+45x7lcqUN6YG5EDxaBiPUN/icC6H3AkpgCyau6Qc36BYOnSa1Dv4L5L8 lUcKXkDKE/bIhN2/56znYJGLa4FlowWVNhUbR1muLRLiQM0k8tJNwElicDAIFqSDO0km oqyTFOgvvLZJJ3kEUXHd0lUBXGNpttNy+HZAO5a7TeT3ltkexw/ObGvVQgnamIG7UdaD +PeEt3HMCiEzjW9UTrcISZYg9NYanbj2EQ93qtw5ZMZYHbp4SCbGBenMNZnJeoU/N+aN DWu9ajBHGAs4VQ6bTQQyW6w3afn66c4cfDB1QYDwzNUTL32zZBY0lhfALbkzuXPY4tcX Y6/Q==
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=uqkekHKEwvK+nMiW2wYWljockfxGIZlMBY61B4YWWCY=; b=oKCwNotX8pAdFOqvNFYdDjSeIgT3zBNZA4gyjcG+3gAMJY5U1Mhb2Ys0L4oLUPuES7 OdGgyuL9DhNk+UJpBAKhhUFH3ozylVMG6dAH0jmr9zuydcVFTAAAKC+d2BCz27gnrPUV 1A6YRNcXrYLGMrCxWt6cF0yS/sunKhhAUamXvmZ9zbCOQ9bm6CfG2tY58u83TMi06LZh j/DAfrhwbGNPzTZXCbksVgMUPBaJGmvO6kPrRlnhKme/NrQ8iVrA4/Rmin89nlpsqgge cU4g0R1IlamcQyz3D1v1MM0N0j7p+K7HdRqQDCqNve8Zl6slT0iatmJsviNFh/AeD5jd bC1g==
X-Gm-Message-State: AOAM5334TXE0qJpW7uVZStItJlSZOP1O1MCiqmnas/rim862dSBpFqrn D7XhTbZsm1ZItg86FItd0IuXHtpVWFDol0mZrnfls9UhRXI7KkZu4yAGe8IYV7vb/p0LRU9bx6d /tQkurp7S/xYaDQ==
X-Google-Smtp-Source: ABdhPJyZhuSiaX44ZCp5NR/qd/OVb7mLoEpNUUxeV+8tQimNbde8va0ms9eE+7+2xaPNZ9I3uIpdpDieVlZ0pZuYbOE=
X-Received: by 2002:a2e:d1a:: with SMTP id 26mr3781242ljn.422.1597182930975; Tue, 11 Aug 2020 14:55:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Tue, 11 Aug 2020 15:55:04 -0600
Message-ID: <>
To: Francis Pouatcha <>
Cc: OAuth WG <>
Content-Type: multipart/alternative; boundary="0000000000003e1fc705aca12105"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt
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: Tue, 11 Aug 2020 21:55:37 -0000

Hi Francis,

My apologies for the tardy response to this - I was away for some time on
holiday. But thank you for the review and feedback on the draft. I've tried
to respond inline below.

On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha <fpo=> wrote:

> Bellow is the only remark I found from reviewing the draft draft:
> 2.1.  Request:
> requires the parameters "code_challenge" and "code_challenge_method" but
> mentions
> that RFC7636 is not required for confidential clients. I guess those two
> parameters have to be taken off the mandatory list and pushed to the list
> below.

The list of parameters in Section 2.1 is qualified with a "basic parameter
set will typically include" and is definitely not intended to convey a set
of required parameters. It's just a list of parameters that make up a
hypothetical typical request.  Perhaps some text in the section or even the
formatting needs to be adjusted so as to (hopefully) avoid any confusion
like this that the list somehow conveys normative requirements?

> - Using jwsreq, non repudiation is provided as request is signed (jws).
> This section also mentions that the request can be sent as form url
> encoded (x-www-form-urlencoded). In this case, there is no way to provide
> non repudiation unless we mention that request can be signed by client
> using signature methods declared by the AS (AS metadata).

 I am not aware of any signature methods or means of an AS declaring
support for a signature method in metadata that are sufficiently
standardized to be mentioned in the context of this draft. The "request"
parameter can
be sent to the PAR endpoint and should provide the same notation of
non-repudiation as does jwsreq. I think that's sufficient treatment of
non-repudiation for the PAR draft.

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