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

> On 11. Aug 2020, at 23:55, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> 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 <fpo=40adorsys.de@dmarc.ietf.org> 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
> https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential-client 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 https://tools.ietf.org/html/draft-ietf-oauth-security-topics and https://tools.ietf.org/html/draft-ietf-oauth-v2-1, 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 https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth