Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[David Waite <[e-mail]>]

> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=[e-mail]> 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.

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.

-DW