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

Torsten Lodderstedt <> Sat, 29 August 2020 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C32D3A13BA for <>; Sat, 29 Aug 2020 05:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, 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 VjqelEx1SQ5B for <>; Sat, 29 Aug 2020 05:26:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A37B3A0891 for <>; Sat, 29 Aug 2020 05:26:21 -0700 (PDT)
Received: by with SMTP id s19so2602002eju.6 for <>; Sat, 29 Aug 2020 05:26:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XaaEZiI9D+NjQX7WfRj5SVgH2/A2ooc0wUJZ/rF389g=; b=sUmmDC/qvlGiIlERrDoDLpvw//O8PTgvRovO0G4krb8AON6iIdGXjx93Nei2X6ZipN znMcGpoKOUvGxBtwSqMmQTx58PuawT7EYmbQLizia7j0mLWTe0rbygAh5gmIOqaft/wR s64QV+4H6fflHHCQjRnrhilmOZGQcJVFrqi5+cvuJFcumegTY38Om7etuP1d0PYg3+HA MZx5VsQ/kMOCxOkA1hmyj+j43gMJKGMAQL2qN+w7Vcfr/AAywOPRcTPN3MueGYVbHnCG jcj+MGqOm7QX1cOyoGW0oB6XIk583AIOAU2C2hfF22j9v6N3+0WfsC4p6/X6Mw6EgPRv ugpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XaaEZiI9D+NjQX7WfRj5SVgH2/A2ooc0wUJZ/rF389g=; b=cpl2vuvG7TAqAZkTFe+Ot2+eIi0Ab1sFLVfvyrfA55C/3X1jZoSeukk09wQLkLned4 EXD7esF/2NLsPtrBEFb4tRXDl37n1sYkrmbITkmsacR5Y7HK59ZND7p7vLjt0galDV1B MSDElOjq5UEERsgw/waGLpyFJjRf3Wb6DSnPMfoRL4TLWy04UK/TrtWb80vQ4Au+UxRz V/6tbNImUGA0ssnwL00uSNLTKg3TfzkBCDgFl+IoSIBy8wWTDf3CQwmQODnuXFEMb64m zjEdM5k4b0oXNhgmKr0muLx8QzwrR1Y6qyeiYSW4RLomvVveB1cJkT8M5G1/pJAT6oAl 1sIg==
X-Gm-Message-State: AOAM533IHQLKZWEfSJg5SPOhHiSQx6rko32iKKKnaHrDmIYO7bhmARMU Gky+fojPiTgKbWXCxLKUqp36qtpDadFZax2w
X-Google-Smtp-Source: ABdhPJykdPtf30EJEiDx2iQCgaETTVaAU04yOSkIa/lwvvQz6DVLQiT8yA123nGYUg+z/wOuT+GSuA==
X-Received: by 2002:a17:906:656:: with SMTP id t22mr3216563ejb.392.1598703979879; Sat, 29 Aug 2020 05:26:19 -0700 (PDT)
Received: from ( [2003:eb:8f1e:2a07:41fe:1768:a10f:1ac2]) by with ESMTPSA id hk14sm2083324ejb.88.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 05:26:19 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Torsten Lodderstedt <>
In-Reply-To: <>
Date: Sat, 29 Aug 2020 14:26:18 +0200
Cc: OAuth WG <>, Brian Campbell <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Francis Pouatcha <>
X-Mailer: Apple Mail (2.3608.
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: Sat, 29 Aug 2020 12:26:24 -0000

> On 11. Aug 2020, at 23:55, Brian Campbell <> wrote:
> 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 <> 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?

Just a note: according to and, code_challenge is a mandatory parameter for any client. That’s why we included it in this list. 

The FAPI WG also considers to make PKCE mandatory in FAPI 1. FAPI 2 requires it anyway. 

> - 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._______________________________________________
> OAuth mailing list