[Openid-specs-fapi] Issue #670: Use of FAPI with mandatory MTLS (openid/fapi)
josephheenan
issues-reply at bitbucket.org
Sat Jan 13 02:41:16 UTC 2024
New issue 670: Use of FAPI with mandatory MTLS
https://bitbucket.org/openid/fapi/issues/670/use-of-fapi-with-mandatory-mtls
Joseph Heenan:
We are continuing to see ecosystems that adopt FAPI but also mandate the use of MTLS on all endpoints.
Certainly in FAPI1 we have seen this with ConnectID, Brazil, UK and CDR - i.e. all the ecosystems we have certification tests for, but we also have indications that other ecosystems might adopt similar approaches.
If MTLS sender constrained access tokens are used this \(which is the only option in FAPI1 and I think still a common choice in FAPI2\) this potentially only affects a few endpoints:
1. Discovery
2. Server JWKS
3. PAR
Several ecosystems mandate the use of MTLS even when using private\_key\_jwt. I think it is a ‘Defence in depth’ type approach, with many security teams having a preference for enforcing MTLS at the perimeter but traffic within the perimeter still having some protection \(i.e. the client authentication assertion\).
The fact that all ecosystems and the main spec diverge in this area is one of the reasons we end up having to create ecosystem specific certification test variants. I think we should discuss it in the WG and consider whether this kind of setup should be included as an option in the specs & certification tests.
\(We did sort of discuss this a little bit here: [https://bitbucket.org/openid/fapi/issues/493/certification-query-supply-of-tls-client](https://bitbucket.org/openid/fapi/issues/493/certification-query-supply-of-tls-client) \)
More information about the Openid-specs-fapi
mailing list