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
<[email protected]> 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
<[email protected]> 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 protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
