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

[George Fletcher <[e-mail]>]

On 2/17/22 4:32 PM, Brian Campbell wrote:
> On Thu, Feb 17, 2022 at 12:28 PM George Fletcher 
> <gffletch=[e-mail]> 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 
> 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.

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.

>
> On 2/14/22 5:51 PM, Brian Campbell wrote:
>> 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 
>> <[e-mail]> 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=[e-mail]> 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
>>         [e-mail]
>>         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./
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> 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./