[Openid-specs-fapi] Issue #493: certification query: supply of TLS client certs & use of mtls_endpoint_aliases (openid/fapi)

[josephheenan]

New issue 493: certification query: supply of TLS client certs & use of mtls_endpoint_aliases
https://bitbucket.org/openid/fapi/issues/493/certification-query-supply-of-tls-client

Joseph Heenan:

I’m no longer sure how to implement TLS client certs and `mtls_endpoint_aliases` in the conformance suite, and would appreciate guidance from the working group:

In FAPIRWID2, this was pretty simple - MTLS sender constraining was required, so regardless of the client authentication in use we had to supply a TLS certificate at every endpoint \(where “every” really means “token endpoint” as that’s the only endpoint that really gets used in the tests\), and hence always used the `mtls_endpoint_aliases` version of the endpoint if one was present.

In FAPI1Adv final, that mostly remained the case, at least until people started using PAR.

In FAPI2Baseline/Advanced, it gets increasingly complex as we consider using DPoP instead of RFC8705 MTLS sender constraining, so there’s now cases where we never supply an MTLS client cert.

The complications happen when ecosystems then decide they also want to require an MTLS client certificate everywhere but want to use private\_key\_jwt client authentication \(I think they’re essentially going for multi-layer defences, i.e. the same reasoning why we have the option for http signatures\).

The current logic the suite has for the token endpoint is essentially:

```
if (usingMTLSClientAuth || usingMTLSSenderConstraining || ecosystemRequiresTLSClientCertEverywhere) {
    supplyMTLSCert = true;
}
url = server["token_endpoint"]
if (supplyMTLSCert && mtlsEndpointAliases.has(“token_endpoint”)) {
    url = mtlsEndpointAliases[“token_endpoint”]
}
```

For the PAR endpoint, it’s similar, except `usingMTLSSenderConstraining` is not checked.

For the user info endpoint, it’s similar except `usingMTLSClientAuth` is not checked.

Part of the reason for this logic is that I think if a self-signed TLS cert is in use for sender-constraining \(combined with private\_key\_jwt client auth\), there’s no requirement in the specs that presenting that self-signed cert at an MTLS aliased PAR endpoint will result in a successful call. \(One option would be to detect a self-signed cert and add that into the above logic.\)

This logic appears to differ from that in at least some clients, where I think they assume that any supplied MTLS cert is just presented at all endpoints, but they use the `mtls_endpoint_aliases` only in the case where at least one element of RFC8705 is in play.

I think the further complexity is just because the server is supporting an ecosystem that requires TLS client certs to be presented everywhere, it isn’t implied that other use cases the server supports will require TLS client certs.

I’m not clear what the correct logic is, but the current situation is giving rise to interoperability issues and would appreciate guidance as to what the correct logic is. \(We also have RP tests that reflect some of this.\)