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

From: Brian Campbell <[email-masked]>
Date: Tue, 11 Aug 2020 15:55:04 -0600

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-masked]> 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.

-- 
_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._

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 18:26:54 -0400

Hello Brian,

On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> 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).
>>
>
> 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
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/

---

From: Brian Campbell <[email-masked]>
Date: Wed, 12 Aug 2020 11:02:41 -0600

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-masked]> wrote:

>>> 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?
>>
>>
>>
> This is not equivalent to jwsreq. As request body is not signed. This does not provide non repudiation.
>

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 12 Aug 2020 13:42:45 -0400

On Wed, Aug 12, 2020 at 1:03 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

> This is what I am looking for. I did oversee this block? Thanks.
/Francis

> [email-masked]..org <[email-masked]>> wrote:
>
>> Hello Brian,
>>
>>> 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.
>>>
>>>
>>>> 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
> *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.*

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 29 Aug 2020 14:26:18 +0200

> On 11. Aug 2020, at 23:55, Brian Campbell <bcampbell=[email-masked]> 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-masked]> wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth