Subject: Re: [OAUTH-WG] WGLC for DPoP Document

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 5 Apr 2022 09:48:58 +0300

I support DPoP publication

--
Vladimir Dzhuvinov

On 28/03/2022 15:01, Rifaat Shekh-Yusef wrote:
> All,
>
> As discussed during the IETF meeting in *Vienna* last week, this is a 
> *WG Last Call *for the *DPoP* document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
> Please, provide your feedback on the mailing list by April 11th.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 8 Apr 2022 11:37:21 +0900

Thanks for an excellent work.
I am happy that the public key confirmation method in JPOP [1] presented at
IETF OAuth WG in 2017 somewhat morphed into DPOP after 5 years. Also, I was
very happy to see the

[1] https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-jpop-00

I also apologize that due to circumstances, I was not able to contribute
much to the work during the time. It is almost the first read for me so
perhaps I could be completely off, but it may also provide the questions
that a new reader may pose.

Here is a set of comments that came to my mind while reading the draft.

   1. It was not immediately clear how the client_id is found from the DPoP
   token request. In the case of JWT Client Authentication, it has `iss` in it
   showing the client_id. In DPoP, it does not, so I am wondering how. Some
   explanatory text would help.
   2. It was not immediately clear how the binding between the key material
   presented in the DPoP header in the token request and the client_id is
   checked. This is critical from the security point of view so if it could be
   explained early on, perhaps in the first paragraph of section 5, it would
   be great.
   3. In Figure 8, it would be great if "cnf" member is formatted as an
   indented JSON member rather than an inline one as it stands.
   4. In Figure 10, it would be great if "cnf" member is formatted as an
   indented JSON member rather than an inline one as it stands.
   5. DPoP Proof Replay described in 11.1 talks about limiting the validity
   period as the mitigation. However, in the case of DPoP Proof Phishing via
   MITM adversary, it is entirely possible that it is only used once, in time,
   by the adversary. So, adding some guidance on server authentication might
   be good to add.

I might come up with some additional ones by the deadline, but for now, the
above is what I have.

Cheers,

Nat Sakimura

On Mon, Mar 28, 2022 at 9:01 PM Rifaat Shekh-Yusef <[email-masked]>
wrote:

> All,
>
> As discussed during the IETF meeting in *Vienna* last week, this is a *WG
> Last Call *for the *DPoP* document:

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "John Bradley" <[email-masked]>
Date: Mon, 11 Apr 2022 18:39:04 +0000

I support publication.

John Bradley

------ Original Message ------
From: "Nat Sakimura" <[email-masked]>
To: "Rifaat Shekh-Yusef" <[email-masked]>; "oauth" 
<[email-masked]>
Sent: 4/7/2022 10:37:21 PM
Subject: Re: [OAUTH-WG] WGLC for DPoP Document

>I am happy that the public key confirmation method in JPOP [1] 
>presented at IETF OAuth WG in 2017 somewhat morphed into DPOP after 5 
>years. Also, I was very happy to see the
>
>I also apologize that due to circumstances, I was not able to 
>contribute much to the work during the time. It is almost the first 
>read for me so perhaps I could be completely off, but it may also 
>provide the questions that a new reader may pose.
>
>It was not immediately clear how the client_id is found from the DPoP 
>token request. In the case of JWT Client Authentication, it has `iss` 
>in it showing the client_id. In DPoP, it does not, so I am wondering 
>how. Some explanatory text would help.
>It was not immediately clear how the binding between the key material 
>checked. This is critical from the security point of view so if it 
>could be explained early on, perhaps in the first paragraph of section 
>5, it would be great.
>In Figure 8, it would be great if "cnf" member is formatted as an 
>In Figure 10, it would be great if "cnf" member is formatted as an 
>DPoP Proof Replay described in 11.1 talks about limiting the validity 
>period as the mitigation. However, in the case of DPoP Proof Phishing 
>via MITM adversary, it is entirely possible that it is only used once, 
>in time, by the adversary. So, adding some guidance on server 
>authentication might be good to add.
>I might come up with some additional ones by the deadline, but for now, 
>the above is what I have.
>
>Cheers,
>
>Nat Sakimura
>
>
>On Mon, Mar 28, 2022 at 9:01 PM Rifaat Shekh-Yusef 
><[email-masked]> wrote:
>>All,
>>
>>As discussed during the IETF meeting in Vienna last week, this is a WG 
>>Last Call for the DPoP document:

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2022 16:29:49 -0600

Thanks Nat,

on 5: Server authentication was kind of assumed throughout the draft due to
HTTPS being required but I think you're right that it might be good to add
something more explicit about it. I'll add something towards that end in
the next revision.
on 3/4: I kind of liked the one line "cnf" in those examples but can change
the formatting to indented to maybe show it more clearly
on 2/1: DPoP doesn't change how the client id is conveyed to the AS. And
the AS binds tokens directly to the DPoP key rather than the client id. So
I'm not sure I understand or know how to answer or address these comments,
to be honest.

On Thu, Apr 7, 2022 at 8:37 PM Nat Sakimura <[email-masked]> wrote:

> I am happy that the public key confirmation method in JPOP [1] presented
> at IETF OAuth WG in 2017 somewhat morphed into DPOP after 5 years. Also, I
> was very happy to see the
>
>    1. It was not immediately clear how the client_id is found from the
>    DPoP token request. In the case of JWT Client Authentication, it has `iss`
>    in it showing the client_id. In DPoP, it does not, so I am wondering how.
>    Some explanatory text would help.
>    2. It was not immediately clear how the binding between the key
>    material presented in the DPoP header in the token request and the
>    client_id is checked. This is critical from the security point of view so
>    if it could be explained early on, perhaps in the first paragraph of
>    section 5, it would be great.
>    5. DPoP Proof Replay described in 11.1 talks about limiting the
>    validity period as the mitigation. However, in the case of DPoP Proof
>    Phishing via MITM adversary, it is entirely possible that it is only used
>    once, in time, by the adversary. So, adding some guidance on server
> On Mon, Mar 28, 2022 at 9:01 PM Rifaat Shekh-Yusef <
> [email-masked]> wrote:
>
>> All,
>>

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