Hi Brian Thanks for this - it will be very useful for open banking in Europe where cert based auth is required by law.
I have a few suggestions around wording. Happy to submit these via pull request if it's helpful. 1. Typo - remove can from 1: Mutual TLS sender constrained access tokens and mutual TLS client authentication are distinct mechanisms that *can* don't necessarily need to be deployed together. 2. Consistency of terminology in 2 (and throughout the document). In section 2 the following phrases are used: - Mutual TLS for Client Authentication - Mutual TLS Client Authentication to the Token Endpoint - mutual TLS as client credentials - mutual X.509 certificate authentication Interestingly RFC5246 does not refer to "mutual authentication" at all, but does refer to "client authentication". >From an OAuth perspective, surely we are more interested in the fact that it is TLS client auth - than the fact that it is mutual. However referring to TLS Client Authentication would bring confusion as we would have two client definitions in play: the TLS Client and the OAuth Client "TLS Mutual Auth" and "Mutual TLS" are established phrases in the industry - even though they don't seem to be defined in any of the relevant specs, however, "Mutual TLS Client Auth" isn't. I'm not sure of the best solution for this, but would be interested as to whether the authors considered this phrasing to be clearer? - Mutual TLS for Client Authentication -> TLS Mutual Auth for Client Authentication - Mutual TLS Client Authentication to the Token Endpoint -> TLS Mutual Auth for Client Authentication to the Token Endpoint - mutual TLS as client credentials -> TLS X509 client certificate as client credentials Or alternatively, a definition of "Mutual TLS" could be provided earlier on in the document. Thanks again for your work on this spec. Dave Tonge
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
