> On 11. Aug 2020, at 23:55, Brian Campbell > <bcampbell=40pingidentity....@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...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
