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