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.


On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha <fpo=
[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
>>>  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._
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to