Subject: Re: [OAUTH-WG] DPoP and client registration metadata

From: Brian Campbell <[email-masked]>
Date: Mon, 14 Feb 2022 15:51:54 -0700

This (more or less) has come up again in the from of a github issue:
https://github.com/danielfett/draft-dpop/issues/105 and it has me sort of
maybe reconsidering the idea of introducing some kind of client metadata
that indicates that the client will always do DPoP. So I wanted to bring it
up again here on the list to try and see what folks had opinions on it.

On Tue, Oct 26, 2021 at 4:08 PM Brian Campbell <[email-masked]>
wrote:

> There are no plans to introduce client registration metadata for DPoP -
> the requirement to use DPoP is more of a property of a resource so I don't
> think registration metadata for a client fits very well.
>
>
> On Tue, Oct 26, 2021 at 8:53 AM Dmitry Telegin <dmitryt=
> [email-masked]> wrote:
>
>> For dynamically registered clients, there is currently no way to indicate
>> the intention to use DPoP. Hence, it's completely up to the AS whether to
>> enforce DPoP or not on such clients (for example, using client registration
>> policies).
>>
>> Seems like there is no common approach here; for example, RFC 8705 (OAuth
>> 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens)
>> does define client registration metadata (see section 9.5), whilst RFC 7636
>> (PKCE) does not. I guess this is due to PKCE being initially conceived as a
>> feature that would become mandatory in OAuth 2.1.
>>
>> Are there any plans to introduce client registration metadata for DPoP?
>>
>> Regards,
>> Dmitry
>> Backbase
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

-- 
_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: George Fletcher <[email-masked]>
Date: Thu, 17 Feb 2022 14:27:59 -0500

From an authorization server perspective, I think it makes sense to be 
able to flag certain clients as only supporting DPoP bound tokens and 
hence rejecting any request without the appropriate proof.

Given that the FAPI 2 baseline is requiring either DPoP or MTLS as the 
sender-constraining methods, I think we need to provide more guidance 
about how DPoP is used in cases outside of SPAs. Can a mobile app using 
dynamic client registration via pub/priv key pair generated on the 
device using the same public key for the DPoP required portions of the 
flows?

Thanks,
George

On 2/14/22 5:51 PM, Brian Campbell wrote:
> https://github.com/danielfett/draft-dpop/issues/105 and it has me sort 
> of maybe reconsidering the idea of introducing some kind of client 
> metadata that indicates that the client will always do DPoP. So I 
> wanted to bring it up again here on the list to try and see what folks 
> had opinions on it.
>
> On Tue, Oct 26, 2021 at 4:08 PM Brian Campbell 
> <[email-masked]> wrote:
>
>     There are no plans to introduce client registration metadata for
>     DPoP - the requirement to use DPoP is more of a property of a
>     resource so I don't think registration metadata for a client fits
>     very well.
>
>
>     On Tue, Oct 26, 2021 at 8:53 AM Dmitry Telegin
>     <dmitryt=[email-masked]> wrote:
>
>         For dynamically registered clients, there is currently no way
>         to indicate the intention to use DPoP. Hence, it's completely
>         up to the AS whether to enforce DPoP or not on such clients
>         (for example, using client registration policies).
>
>         Seems like there is no common approach here; for example, RFC
>         8705 (OAuth 2.0 Mutual-TLS Client Authentication and
>         Certificate-Bound Access Tokens) does define client
>         registration metadata (see section 9.5), whilst RFC 7636
>         (PKCE) does not. I guess this is due to PKCE being initially
>         conceived as a feature that would become mandatory in OAuth 2.1.
>
> /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: Brian Campbell <[email-masked]>
Date: Thu, 17 Feb 2022 14:32:27 -0700

On Thu, Feb 17, 2022 at 12:28 PM George Fletcher <gffletch=
[email-masked]> wrote:

> able to flag certain clients as only supporting DPoP bound tokens and hence
> rejecting any request without the appropriate proof.
>

There's work underway over in github to get that into the next draft.
Though there's still discussion about the scope of what the metadata
indicates the client will do and the AS should require.

> sender-constraining methods, I think we need to provide more guidance about
> how DPoP is used in cases outside of SPAs. Can a mobile app using dynamic
> client registration via pub/priv key pair generated on the device using the
> same public key for the DPoP required portions of the flows?
>

It could use the same key but there's nothing requiring it or checking any
association. In
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html#section-1-3
we say "DPoP can be used to sender-constrain access tokens regardless of
the client authentication method employed, but DPoP itself is not used for
client authentication." Which is meant to say that DPoP is orthogonal to
client auth.

> that indicates that the client will always do DPoP. So I wanted to bring
> it up again here on the list to try and see what folks had opinions on it.
>
>>> For dynamically registered clients, there is currently no way to
>>> indicate the intention to use DPoP. Hence, it's completely up to the AS
>>> whether to enforce DPoP or not on such clients (for example, using client
>>> registration policies).
>>>
>>> Seems like there is no common approach here; for example, RFC 8705
>>> (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access
>>> Tokens) does define client registration metadata (see section 9.5), whilst
>>> RFC 7636 (PKCE) does not. I guess this is due to PKCE being initially
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Feb 2022 18:29:02 -0500

On 2/17/22 4:32 PM, Brian Campbell wrote:
> On Thu, Feb 17, 2022 at 12:28 PM George Fletcher 
> <gffletch=[email-masked]> wrote:
>
>     Given that the FAPI 2 baseline is requiring either DPoP or MTLS as
>     the sender-constraining methods, I think we need to provide more
>     guidance about how DPoP is used in cases outside of SPAs. Can a
>     mobile app using dynamic client registration via pub/priv key pair
>     generated on the device using the same public key for the DPoP
>     required portions of the flows?
>
>
> It could use the same key but there's nothing requiring it or checking 
> any association. In 
> we say "DPoP can be used to sender-constrain access tokens regardless 
> of the client authentication method employed, but DPoP itself is not 
> used for client authentication." Which is meant to say that DPoP is 
> orthogonal to client auth.

Ok, I guess I was wondering if there are any security implications of 
using the same key or benefits of using different keys that might be 
helpful for developers.

>> https://github.com/danielfett/draft-dpop/issues/105 and it has me 
>> sort of maybe reconsidering the idea of introducing some kind of 
>> client metadata that indicates that the client will always do DPoP. 
>> So I wanted to bring it up again here on the list to try and see what 
>> folks had opinions on it.
>>
>> privileged material for the sole use of the intended recipient(s). 
>> Any review, use, distribution or disclosure by others is strictly 
>> notify the sender immediately by e-mail and delete the message and 
>> any file attachments from your computer. Thank you./
>>