Hello Brian, On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell <bcampbell= [email protected]> 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= > [email protected]> 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? > > > >> - 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. > This is the case when PAR uses "Content-type: application/oauth.authz.req+jwt". This is fine as the jws form param is signed. This is also equivalent to jwsreq in matter of providing non repudiation. Content-Type: application/x-www-form-urlencoded .... request=eyJraWQiOiJrMmJ.....3Gkk488RQohhgt1I0onw This is not equivalent to jwsreq. As request body is not signed. This does not provide non repudiation. Content-Type: application/x-www-form-urlencoded .... response_type=code& state=af0ifjsldkj It is worth mentioning this in the draft Best regards /Francis -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
