> 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.
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
