On Wed, Aug 12, 2020 at 1:03 PM Brian Campbell <bcampbell= [email protected]> wrote:
> I'm honestly having a hard time following what you are asking for. But > there is already the following text in sec 1 that mentions non-repudiation > via JWT-based request objects and by implication the basic request method > does not provide non-repudiation. > > The pushed authorization request endpoint fosters OAuth security by > providing all clients a simple means for a confidential and integrity > protected authorization request, but it also allows clients requiring > an even higher security level, especially cryptographically confirmed > non-repudiation, to explicitly adopt JWT-based request objects. > > This is what I am looking for. I did oversee this block? Thanks. /Francis > > On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha <fpo= > [email protected] <[email protected]>> wrote: > >> 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 >>>> <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/ >> > > *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.* -- 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
