MTLS aliases ambiguity in private_key_jwt client authentication

[Joseph Heenan]

The CIBA spec says (on the topic of the aud for private key jwt client authentication assertions):

To facilitate interoperability, the OP MUST accept its Issuer Identifier, Token Endpoint URL, or Backchannel Authentication Endpoint URL as values that identify it as an intended audience.

The certification team just ran into an OP that rejects it’s non-mtls token endpoint url as the audience for an assertion used at the mtls backchannel authentication endpoint and hence failed a test. I’m unsure what’s the correct way to combine the above text with aliases defined in https://datatracker.ietf.org/doc/html/rfc8705#section-5 so it seems there’s perhaps a remaining ambiguity.

‌

[Joseph Heenan]

To state the question perhaps more succinctly (or at least differently):

When a server has used mtls_endpoint_aliases to define a mtls version of the token endpoint (for the purposes of issuing certificate-bound access tokens), is it required to support [at the backchannel authentication endpoint] the client assertion aud being:

1. The non-mtls token endpoint only
2. The mtls token endpoint only
3. Both

‌

[Brian Campbell]

I’ve had a sneaking suspicion that there were some variations of private_key_jwt aud and MTLS that could be problematic. But couldn’t quite reason about when or how they’d manifest. Or what to do about it.

IMHO as the perpetrator of most/all the text underlying the problem here, the intent was what you’ve got as # 1. To have the AS accept the regular non-mtls token endpoint as an aud value as a means of staying consistent and compatible with the 'legacy' text of RFC7523 and OIDC core while encouraging/allowing for the transition towards using the issuer value as the aud (which itself is less likely to encounter these kinds of issues).

‌

[Joseph Heenan]

Thanks Brian!

That seems logical to me, and happens to be what the tests already do.

I guess the remaining question was whether we feel the need to add any clarification to the spec. I’m kind of reluctant to do so, mostly because I can’t find a wording that does so without ending up with a statement that feels unnecessarily complex.

[Brian Campbell]

While it’s all admittedly somewhat convoluted, I do think that that conclusion does follow logically from the current text. Also I concur that attempts at further clarification will likely be unnecessarily complex and fear they’d do more harm to general comprehensibility of the doc than help. As such, I suggest closing this ticket without changes to the draft.

‌

[Bjorn Hjelm]

Per discussion on today’s call, it was agreed to close the issue without any additional text.