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

[Brian Campbell <[e-mail]>]

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

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

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.


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


>
> 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 [e-mail]://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._