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

[George Fletcher <[e-mail]>]

 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:
> 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