On 9 Jan 2019, at 05:54, David Waite <da...@alkaline-solutions.com> wrote: > >> On Dec 28, 2018, at 3:55 PM, Brian Campbell >> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: >> > <snip> > >> All of that is meant as an explanation of sorts to say that I think that >> things are actually okay enough as is and that I'd like to retract the >> proposal I'd previously made about the MTLS draft introducing a new AS >> metadata parameter. It is admittedly interesting (ironic?) that Neil sent a >> message in support of the proposal as I was writing this. It did give me >> pause but ultimately didn't change my opinion that it's not worth it to add >> this new AS metadata parameter. > > Note that the AS could make a decision based on the token endpoint request - > such as a policy associated with the “client_id”, or via a parameter in the > ilk of “client_assertion_type” indicating MTLS was desired by this public > client installation. The AS could then to TLS 1.2 renegotiation, 1.3 > post-handshake client authentication, or even use 307 temporary redirects to > another token endpoint to perform mutual authentication.
Renegotiation is an intriguing option, but it has some practical difficulties. Our AS product runs in a Java servlet container, where it is pretty much impossible to dynamically trigger renegotiation without accessing private internal APIs of the container. I also don’t know how you could coordinate this in the common scenario where TLS is terminated at a load balancer/reverse proxy? A 307 redirect could work though as the server will know if the client either uses mTLS for client authentication or has indicated that it wants certificate-bound access tokens, so it can redirect to a mTLS-specific endpoint in those cases. > Both the separate metadata url and a “client_assertion_type”-like indicator > imply that the client has multiple forms of authentication and is choosing to > use MTLS. The URL in particular I’m reluctant to add support for, because I > see it more likely a client would use MTLS without knowing it (via a > device-level policy being applied to a public web or native app) than the > reverse, where a single client (represented by a single client_id) is > dynamically picking between forms of authentication. That’s an interesting observation. Can you elaborate on the sorts of device policy you are talking about? I am aware of e.g. mobile device management being used to push client certificates to iOS devices, but I think these are only available in Safari. — Neil _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
