The objective is to allow the AS to provide MTLS negotiating endpoints on a different host and/or port so that any non-desirable side effects of requesting client certificates during the TLS handshake can be avoided for 'regular' clients that are not doing any MTLS.
In all likelihood, I'd expect that any pair of MTLS and regular endpoints have the same application logic behind them. And that just the TLS setup that differs to accommodate the aforementioned objective. That means that they'd support the same client authentication methods but the MTLS endpoint would just be set up so as to get MTLS to work. When first considering it, that seemed a bit overreaching for the spec to come out and say and more of a deployment thing for the AS. But maybe being more prescriptive would reduce some of the professed problematic ambiguity. As mentioned in a previous message, referring to the mtls endpoints as aliases might be useful in indicating that they are the same endpoint that is just known and accessed differently based on the context of use. I'll grant that some of the wording in RFC 8414 can be awkward with respect to this kind of extension. Calling it a violation is a bit over the top though. And as much as we might try to write specs that are the final word, there's the realities of how usage and understanding unfold in practice. As one example, there's some discussion of the treatment of some of the metadata in this section of a blog post about a different spec being developed https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00. Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being pragmatic in the given circumstances. I suppose opinions will differ. It turns out that writing these specifications is kinda hard. Even when people share the same objective (and that's often not even the case), opinions can differ about what actually constitutes simplicity. It seems that's where we are now. My stance as an individual is that the mtls_endpoints (or mtls_endpoint_aliases) approach is reasonable and pragmatic and the most straightforward and simple of the options put forth (i.e. vs a metadata parameter linking to or well-known locations to completely separate metadata documents). As an editor, I acknowledge that there's been disagreement about it while also noting again that the dissenting voices come from a vocal minority of a few individuals. On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle <richanna= 40amazon....@dmarc.ietf.org> wrote: > Neil’s example demonstrates how the mtls_endpoints approach leads to > confusion. Consider the following metadata fragment: > > > > { > > “token_endpoint”: “https://as.example.com/token”, > > “token_endpoint_auth_methods_supported”: [ “client_secret_basic”, > “tls_client_auth” ], > > “mtls_endpoints”: { > > “token_endpoint”: “https://as.example.com/mtls/token” > > } > > } > > > > Which of these statements about endpoints on https://as.example.com/ are > true? > > 1. The /token endpoint only supports client_secret_basic, and > /mtls/token only supports tls_client_auth. > 2. The /token endpoint supports both methods, and /mtls/token only > supports tls_client_auth. > 3. Both /token and /mtls/token support both methods. > > > > All of these could be reasonable interpretations of this metadata. When > properties mean different things in different contexts, ambiguity abounds.. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
