Free DPoP

[Brian Campbell]

Baseline has "shall only issue sender-constrained access tokens using Mutual TLS as described in [@!RFC8705]" for servers and "shall support sender-constrained access tokens using Mutual TLS as described in [@!RFC8705]" for clients.

Why not allow for DPoP too?

MTLS just isn't accessible in a lot of cases and mandating it is severely limiting the applicability of FAPI2.

[Brian Campbell]

Ralph: “Dpop support would be great as it would potentially give an avenue for fapi compliant mobile based confidential clients that can’t rely on mtls.“ -http://lists.openid.net/pipermail/openid-specs-fapi/2020-November/002170.html

[Joseph Heenan]

+1 for allowing DPoP in FAPI2. (Even though that means a bunch of extra work on the conformance tests, and even though I suspect it’ll cause extra pain because some ecosystems will choose to have their resource servers require DPoP in addition to some form of mutual tls…)

‌

[Filip Skokan]

FAPI 2.0 baseline with private_key_jwt and DPoP means there’s no need to deploy MTLS (for the sake of mTLS sender constraining).

+1

[Daniel Fett]

Add DPoP to FAPI 2, fix #341

→ <<cset fcfb28cd93a2>>

[Daniel Fett]

Of course, DPoP should be in FAPI 2. Added as an option!

[Brian Campbell]

https://bitbucket.org/openid/fapi/branch/danielfett/fapi2/wg-feedback is a branch with changes for this and a number of other issues but has been there unmerged for a couple months…

‌

[Daniel Fett]

I didn’t notice that the branch was not merged yet, thanks for the ping. Any new changes shall go into separate branches/PRs.