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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Jan 2019 15:55:40 -0600

On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
> 
> The observed behavior of the browsers surveyed seems logical and rather
> reasonable (and better than the last time I futzed with it). Importantly it
> means that for the situation described in the email that started this
> thread (a javascript client making a fetch/XHR request to an MTLS token
> endpoint), users using browsers that are not configured with, or have
> access to, any client keys/certs will not see any UI prompt at all. I
> suspect that not having client certs set up is the situation for the vast
> majority of users and their browsers. And for those that do have client

Is this still true when we limit to the set of users/browsers that are
employees of big corporations?

-Ben

> certs set up, I think they are more likely to be the kind of user that is
> able to deal with the UI prompt okay.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 7 Jan 2019 10:21:51 -0700

I don't honestly know for sure but I suspect that employees of big
corporations will likely have keys/certs on their devices/machines that are
issued by some internal CA and provisioned to them automatically (and in
many cases without the user knowing and/or understanding that they are
there and why). Those users would likely be prompted when TLS handshaking
with a server that presents an empty list of CAs in the
certificate_authorities of the CertificateRequest.

I dunno. Maybe I was too quick to retract the proposal for the MTLS
supporting secondary token endpoint?

What do folks (including Ben & Neil) think?

On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk <[email-masked]> wrote:

> > I

-- 
_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._

---

From: Filip Skokan <[email-masked]>
Date: Mon, 7 Jan 2019 19:15:37 +0100

I think we shouldn't make a sweeping assumption that may potentially harm
UX for end-users. Even if for a small percentage. Tho i can say for sure
this percentage may also be rather significant depending on the types of
services end-users have encountered in the past and made them install certs.

For example, in Czech Republic there's an online system for communicating
with government agencies, essentially an email-like inbox that you only get
when verifying your identity in person on a post office, every company is
required to have one for communication e.g. with the tax office and
individuals and freelancers are encouraged to have one as well. To finish
signing up for this inbox online after you've verified your identity in
person, you must install custom certificates on your system otherwise the
browser won't let you through the online signup part due to HSTS. I can say
with 100% confidence that most folk do not remove these certs from their
system, this means they'd fall in the category that gets prompted and are
in majority nowhere near the kind of users that are able to deal with the
UI prompt when encountered in the wild.

I'd like to see a solution that

   - works for every endpoint that needs mtls client cert for either client
   auth or certificate bound token validation. This isn't only a case for
   token endpoint, introspection, revocation, userinfo (RS-like endpoint that
   might be checking a cert bound access token) to list a few
   - can ensure clients without access to client certificates won't hit an
   endpoint configured to request one to avoid the change of having the UX
   flow broken, potentially selecting the wrong certificate which the browser
   then remembers to use thus failing auth until website data is cleared.

Working under the assumption a client software always knows whether it is
configured with client certificates or not it would be nice if there was
either a defined prefix, suffix or a specific object in the discovery
response (with the same endpoint names in it) that a client can rely on to
detect if there is an mtls specific url for any discovered endpoint it
needs to use when providing client certificates.

Best,
*Filip*

On Mon, Jan 7, 2019 at 6:22 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Mon, 7 Jan 2019 18:36:29 +0000

Thinking about this, given that this is the *token* endpoint that clients talk to directly, not the *authorize* endpoint, it seems already possible for the AS to put it on a different port/host so that users aren’t ever prompted for a cert. Right?

— Neil

> On 7 Jan 2019, at 17:21, Brian Campbell <[email-masked]> wrote:
> 
> I don't honestly know for sure but I suspect that employees of big corporations will likely have keys/certs on their devices/machines that are issued by some internal CA and provisioned to them automatically (and in many cases without the user knowing and/or understanding that they are there and why). Those users would likely be prompted when TLS handshaking with a server that presents an empty list of CAs in the certificate_authorities of the CertificateRequest. 
> 
> I dunno. Maybe I was too quick to retract the proposal for the MTLS supporting secondary token endpoint?
> 
> 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.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 8 Jan 2019 05:59:55 -0700

inline below...

> UI prompt when encountered in the wild.

In this example, the custom certificates one has to install on their system
are additional root CAs, right?  From my observations that has no bearing
on the prompting behavior of the browsers (and shouldn't). What dictates
the behavior is whether the browser is configured with, or has access to,
one or more certificate with the associated private key that could be used
as client TLS certificates.

>    - works for every endpoint that needs mtls client cert for either
>    client auth or certificate bound token validation. This isn't only a case
>    for token endpoint, introspection, revocation, userinfo (RS-like endpoint
>    that might be checking a cert bound access token) to list a few
>    - can ensure clients without access to client certificates won't hit
>    an endpoint configured to request one to avoid the change of having the UX

Yeah, you are right about other endpoints (I'd been kind of willfully
ignoring them to be honest) and I think the specific object in the
discovery response that itself could have any of the same endpoint names in
it would be the most straight forward way to approach that.

Best,
>> 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
>> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Tue, 8 Jan 2019 06:04:17 -0700

Yes *but* not when the client is a javascript application running in the
user's browser. And the direction this WG is taking is to start/continue to
suggest that such clients use the code flow (which hits the token endpoint)
rather than the implicit (which only hits the authorization endpoint).

On Mon, Jan 7, 2019 at 11:36 AM Neil Madden <[email-masked]>
wrote:

> Thinking about this, given that this is the *token* endpoint that clients
> talk to directly, not the *authorize* endpoint, it seems already possible
> for the AS to put it on a different port/host so that users aren’t ever
> prompted for a cert. Right?
>
> — Neil
>
> review, use, distribution or disclosure by others is strictly prohibited.
> your computer. Thank you.*
>
>

---

From: Filip Skokan <[email-masked]>
Date: Tue, 8 Jan 2019 16:38:54 +0100

>
> In this example, the custom certificates one has to install on their
> system are additional root CAs, right?

Correct,* in this example.*

> From my observations that has no bearing on the prompting behavior of the
> browsers (and shouldn't). What dictates the behavior is whether the browser
> is configured with, or has access to, one or more certificate with the
> associated private key that could be used as client TLS certificates.

*with the associated private key* - hmm, does that explain my observation
then (tested on OS X Chrome and FF) the result was that supporting both
self-signed and PKI client auth method on the token (+introspection,
revocation) endpoints and support for cert bound access tokens on the
userinfo_endpoint for non-browser based clients while not prompting on
token, userinfo or revocation calls made from the browser.

This was my nginx server block
https://gist.github.com/panva/bb153c974cfd65fb0bc9ebb89ca0a3eb

Is that a valid setup? I honestly don't know, it seemed to fit the bill for
this particular AS configuration. But without the option to discover mtls
specific endpoints it's seems to be the only one usable for an AS that also
has browser-based clients, one couldn't use `on` or `optional`
configuration - are we in the position to restrict the possible
configuration to just one? nah.

If we consider having an `mtls_endpoints` or similar object in discovery
then this whole problem and potential broken UX goes away, or rather, will
only come up for browser based clients on e.g. provisioned hardware that
access sites like company's intranet etc. and is developed with using those
certs and therefore directly accessing the mtls_endpoints discovery
namespace.
The logic is also rather simple for a regular backend client
implementation, if there's a client cert, look for that object's endpoint
(and fallback to the usual if missing). If the client doesn't support
sending mtls client certs, it will continue using the regular endpoints.
The use of `mtls_endpoints` is optional but when used guarantees that
browser based clients will never have randomly broken UX for some users. I
can only imagine the support cases horror from customer's end-users who
don't know what to do.

It was, afterall, the original intention behind this section of the draft.

The authorization server may also consider hosting the token endpoint, and
other endpoints requiring client authentication, on a separate host name or
port in order to prevent unintended impact on the TLS behavior of its other
endpoints, e.g. the authorization endpoint.

S pozdravem,
*Filip Skokan*

On Tue, Jan 8, 2019 at 2:00 PM Brian Campbell <[email-masked]>
wrote:

> In this example, the custom certificates one has to install on their
> system are additional root CAs, right?  From my observations that has no
> bearing on the prompting behavior of the browsers (and shouldn't). What
> dictates the behavior is whether the browser is configured with, or has
> access to, one or more certificate with the associated private key that
> could be used as client TLS certificates.
>
>
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Jan 2019 17:56:23 -0600

> What do folks (including Ben & Neil) think?

Sorry for the slow reply.  I agree with Filip that we can't be confident
that the affected population is a vanishingly small population, so it
probably does make sense to continue thinking about how we can present a
better UX.

-Ben

---

From: David Waite <[email-masked]>
Date: Tue, 8 Jan 2019 22:29:58 -0700

> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> I spent some time this holiday season futzing around with a few different browsers to see what kind of UI, if any, they present to the user when seeing different variations of the server requesting a client certificate during the handshake. 
> 
> In a non-exhaustive and unscientific look at the browsers I had easily at my disposal (FF, Chrome, and Safari on Mac OS), it seems they all behave basically the same. If the browser is configured with, or has access to, one or more client certificates that match the criteria of the CertificateRequest message from the server (basically if issued by one of the CAs in the certificate_authorities of the CertificateRequest), a certificate selection UI prompt will be presented to the user. Otherwise, a certificate selection UI prompt is not presented all. When the CertificateRequest message has an empty certificate_authorities list (likely the case with a optional_no_ca type config), the browsers look for client certificates with any issuer rather than narrowing it down. 

Was your testing via XHR/fetch?

FWIW,

Firefox behavior is determined by a global pick automatically / prompt every time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt <https://wiki.mozilla.org/PSM:CertPrompt>

Safari on macOS relies on the keychain, where a record is created called an Identity Preference. This is a URL (https or email) to preferred certificate mapping. Previously, it would create this record the first time a user selected a certificate, then never prompt again.

Chrome seems to delegate to the underlying OS for certificate management, so on the Mac it has this behavior as well. This means however that other platforms may have different behaviors.

Safari on iOS used to automatically select a single certificate match, if the query was for a single client CA. I didn’t try with other small numbers (2, 3, etc) but when exposing the list of all available CAs as valid client CAs, it would prompt. This may not be the heuristic anymore, as knowing the name of a client CA (such one issued as part of a cloud EMM deployment) would allow certificates to be used for tracking.

IE (pre-edge) would allow the behavior to use an automatic cert or prompt to be configured per-zone, which would allow policy to send a device/user identification certificate to a particular set of sites by default. I have no experience with configuring Edge, unfortunately.

-DW

---

From: David Waite <[email-masked]>
Date: Tue, 8 Jan 2019 22:54:43 -0700

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

---

From: Neil Madden <[email-masked]>
Date: Fri, 11 Jan 2019 10:32:16 +0000

> 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 MT…

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 relucta…

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

---

From: Filip Skokan <[email-masked]>
Date: Fri, 11 Jan 2019 12:50:51 +0100

307 indeed seems doable, similar to a discovery namespace it requires the
client software to be prepared for this and follow the redirect in that
case, but in David’s case it doesn’t require the client to “know” it is
bound to a device wide policy. The client just assumes it has no form of
authentication and only sends the client_id.

I’ll try to do a quick PoC for 307 and share any findings i may have.

Renegotiation not only isn’t easy to do in some common setups (self managed
tls terminating LB or proxy), but in some is outright impossible - e.g.
managed services like AWS ALB or API Gateway that may be in use for regular
requests and with self-hosted endpoints running nxinx/apache for just mtls
requests on the side.

Best,
*Filip*

On Fri, Jan 11, 2019 at 11:32 AM Neil Madden <[email-masked]>
wrote:

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

---

From: David Waite <[email-masked]>
Date: Fri, 11 Jan 2019 12:32:32 -0700

> On Jan 11, 2019, at 3:32 AM, Neil Madden <[email-masked]> wrote:
> 

Agreed. There are trade-offs for both. As you say, I don’t know a way to have say a custom error code or WWW-Authenticate challenge to trigger renegotiation on the reverse proxy - usually this is just a static, location-based directive.

> 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 d…

The primary use is to set policy to rely on device level management in controlled environments like enterprises when available. So an AS may try to detect a client certificate as an indicator of a managed device, use that to assume a device with certain device-level authentication, single user usage, remote wipe, etc. characteristics, and decide that it can reduce user authentication requirements and/or expose additional scopes.

On more thought, this is typically done as part of the user agent hitting the authorization endpoint, as a separate native application may be interacting with the token endpoint, and in some operating systems the application’s network connections do not utilize (and may not have access to) the system certificate store.

In terms of user agents, I believe you can perform similar behavior (managed systems using client certificates on user agents transparently) on macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typically inherits device level policy. Firefox on desktop I assume you can do that in limited fashion as well.

-DW

---

From: Brian Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 11:41:42 -0700

No, my testing was not via XHR/fetch. Just direct request from the browser.
I was making the assumption (maybe foolishly) that it wouldn't impact
behavior because it's all at the network layer.

I saw that Firefox setting but left the default (at least for my install),
which was not to autopick.

On Tue, Jan 8, 2019 at 10:30 PM David Waite <[email-masked]>
wrote:

> Firefox behavior is determined by a global pick automatically / prompt
> every time flag. Details at https://wiki.mozilla.org/PSM:CertPrompt
>
> Safari on macOS relies on the keychain, where a record is created called
> an Identity Preference. This is a URL (https or email) to preferred
> certificate mapping. Previously, it would create this record the first time
> a user selected a certificate, then never prompt again.
>
> Chrome seems to delegate to the underlying OS for certificate management,
> so on the Mac it has this behavior as well. This means however that other
> platforms may have different behaviors.
>
> Safari on iOS used to automatically select a single certificate match, if
> the query was for a single client CA. I didn’t try with other small numbers
> (2, 3, etc) but when exposing the list of all available CAs as valid client
> CAs, it would prompt. This may not be the heuristic anymore, as knowing the
> name of a client CA (such one issued as part of a cloud EMM deployment)
> would allow certificates to be used for tracking.
>
> IE (pre-edge) would allow the behavior to use an automatic cert or prompt
> to be configured per-zone, which would allow policy to send a device/user
> identification certificate to a particular set of sites by default. I have
> no experience with configuring Edge, unfortunately.
>
> -DW
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 14:28:59 -0700

Trying to summarize things somewhat here and focus in hopefully towards
some decision. There's basically an idea on the table to add an AS metadata
parameter to the draft-ietf-oauth-mtls doc that would be a JSON object
which contains endpoints that a client doing MTLS would use rather than the
regular endpoints. A straw-man example might look like this (with
mtls_endpoints being that new parameter).

{
  "issuer":"https://server.example.com",
  "authorization_endpoint":"https://server.example.com/authz",
  "token_endpoint":"https://server.example.com/token",
  "token_endpoint_auth_methods_supported":[
"client_secret_basic","tls_client_auth", "none"],
  "userinfo_endpoint":"https://server.example.com/userinfo",
  "revocation_endpoint":"https://server.example.com/revo",
  "jwks_uri":"https://server.example.com/jwks.json",

*  "mtls_endpoints":{      "token_endpoint":"https://mtls.example.com/token
<https://mtls.example.com/token>",    "userinfo_endpoint":"https://mtls
<https://server.example.com/token>.example.com/userinfo
<http://example.com/userinfo>",    "revocation_endpoint":"https://mtls
<https://server.example.com/token>.example.com/revo
<http://example.com/revo>"  }*
}

The idea behind this is that "regular" clients (those not doing MTLS) will
use the regular endpoints. And only the host/port of the endpoints listed
in mtls_endpoints will be set up to request TLS client certificates during
handshake. Thus any potential impact of the CertificateRequest message
being sent in the TLS handshake can be avoided for all the other regular
clients that are not going to do MTLS - including and most importantly
in-browser javascript clients where there can be less than desirable UI
presented to the end-user.

The arguments in favor of that seem to be basically that it allows for AS
deployments to support MTLS while still allowing for a "not broken" UX for
end-users of clients (in-browser javascript clients) that aren't doing
MTLS. And that it's not much in terms of adding to the spec and complexity
of implementations.

The arguments against it seem to be 1) the bad UX isn't really that bad
and/or will only happen to a subset of users 2) there are other things that
can be done, such as 307ing or renegotiation/post-handshake client auth, to
avoid the bad UX.

Speaking for myself, I'm kinda torn on it.

I will say that, in addition to the folks that have pointed out that
renegotiation just isn't possible in some cases, my experience trying to do
something like that in the past was not particularly successful or
encouraging. That could have been my fault, of course, but still seems a
relevant data point. I also have my doubts about the actual difficulty of
getting an AS to issue a 307 like response for requests based on the
calling client and the likelihood that some/all OAuth client software would
handle it appropriately.

On Fri, Jan 11, 2019 at 12:32 PM David Waite <[email-masked]>
wrote:

> Agreed. There are trade-offs for both. As you say, I don’t know a way to
> have say a custom error code or WWW-Authenticate challenge to trigger
> renegotiation on the reverse proxy - usually this is just a static,
> location-based directive.
>
> >
> The primary use is to set policy to rely on device level management in
> controlled environments like enterprises when available. So an AS may try
> to detect a client certificate as an indicator of a managed device, use
> that to assume a device with certain device-level authentication, single
> user usage, remote wipe, etc. characteristics, and decide that it can
> reduce user authentication requirements and/or expose additional scopes.
>
> On more thought, this is typically done as part of the user agent hitting
> the authorization endpoint, as a separate native application may be
> interacting with the token endpoint, and in some operating systems the
> application’s network connections do not utilize (and may not have access
> to) the system certificate store.
>
> In terms of user agents, I believe you can perform similar behavior
> (managed systems using client certificates on user agents transparently) on
> macOS, Windows, Chrome, and Android devices, Chrome (outside iOS) typically
> inherits device level policy. Firefox on desktop I assume you can do that
> in limited fashion as well.
>
> -DW

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 14 Jan 2019 22:09:44 -0600

On just one narrow point...

> relevant data point. I also have my doubts about the actual difficulty of

Also, the TLS folks get sad when we come up with new applications of
renegotiation -- its removal from TLS 1.3 made many people happy.

-Ben

---

From: Dave Tonge <[email-masked]>
Date: Tue, 15 Jan 2019 10:04:34 +0100

I'm in favour of the `mtls_endpoints` metadata parameter - although it
should be optional.
While a 307 redirect seems kind of elegant I worry, like you,  that not all
clients would handle it appropriately.
There would probably need to be an error defined for clients who attempt to
use `tls_client_auth` at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=
[email-masked]> wrote:

> *  "mtls_endpoints":{
> "token_endpoint":"https://mtls.example.com/token

---

From: Filip Skokan <[email-masked]>
Date: Tue, 15 Jan 2019 10:30:34 +0100

I'm in favour of both 307 and metadata.

   - case 307 - I don't recall ever encountering an http client software
   that wouldn't have an option for following redirects, same for a server
   side frameworks not having the option to do a 307 response with a location
   header.
   - case 307 - Relying purely on a new metadata doesn't help in the
   scenario David put forth earlier about clients not being aware of using
   mtls, a device policy of sorts.
   - case metadata - no second request if the client knows there's an mtls
   endpoint it should use.

Maybe we should specify both as optional for an AS to deploy and a client
to be ready for?

S pozdravem,
*Filip Skokan*

On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <[email-masked]>
wrote:

> While a 307 redirect seems kind of elegant I worry, like you,  that not
> all clients would handle it appropriately.
> There would probably need to be an error defined for clients who attempt
> to use `tls_client_auth` at the regular endpoint.
>
> Dave
>
>> <https://server.example.com/token>..example.com/revo
>> The idea behind this is that "regular" clients (those not doing MTLS)
>> will use the regular endpoints. And only the host/port of the endpoints
>> listed in mtls_endpoints will be set up to request TLS client certificates
>> during handshake.. Thus any potential impact of the CertificateRequest
>> message being sent in the TLS handshake can be avoided for all the other
>> regular clients that are not going to do MTLS - including and most
>> importantly in-browser javascript clients where there can be less than
>> desirable UI presented to the end-user.
>>
>> On Fri, Jan 11, 2019 at 12:32 PM David Waite <
>> [email-masked]> wrote:
>>
>>>
>>>
>>> On more thought, this is typically done as part of the user agent
>>> hitting the authorization endpoint, as a separate native application may be

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Jan 2019 06:48:42 -0700

It would definitely be optional, apologies if that wasn't made clear. It'd
be something to the effect of optional for the AS to include and clients
doing MTLS would use it when present in AS metadata.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Jan 2019 06:54:31 -0700

I don't know that the use of 307 would need to be discussed in the document
itself.

On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <[email-masked]> wrote:

>    - case metadata - no second request if the client knows there's an
>    mtls endpoint it should use.
>
>>>   "userinfo_endpoint":"https://server..example.com/userinfo
>>> <https://server.example.com/userinfo>",
>>> The arguments in favor of that seem to be basically that it allows for
>>> AS deployments to support MTLS while still allowing for a "not broken" UX
>>> for end-users of clients (in-browser javascript clients) that aren't doing
>>>> > 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.
>>>>
>>>> Agreed. There are trade-offs for both. As you say, I don’t know a way
>>>> to have say a custom error code or WWW-Authenticate challenge to trigger
>>> prohibited....  If you have received this communication in error, please

---

From: Filip Skokan <[email-masked]>
Date: Tue, 15 Jan 2019 14:58:51 +0100

>
> I don't know that the use of 307 would need to be discussed in the
> document itself.

If the clients are supposed to be ready for this, yeah. For instance, my
client software by default doesn't follow redirects, in order for it to be
ready for mtls client authentication i'd have to know 307 is a possibility
and whitelist 307 as a valid code to be followed.

S pozdravem,
*Filip Skokan*

On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <[email-masked]>
wrote:

> I don't know that the use of 307 would need to be discussed in the
> document itself.
>
>>>>> >>> 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.
>>>>> >>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 16 Jan 2019 05:52:00 -0700

I guess I should have also said or been more straightforward in saying that
I don't particularly want to try and discuss/define the use of a 307 in the
document.

On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <[email-masked]> wrote:

>>>    - case 307 - I don't recall ever encountering an http client
>>>    software that wouldn't have an option for following redirects, same for a
>>>    server side frameworks not having the option to do a 307 response with a
>>>    location header.
>>> Maybe we should specify both as optional for an AS to deploy and a
>>> client to be ready for?
>>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>>> There would probably need to be an error defined for clients who
>>>> attempt to use `tls_client_auth` at the regular endpoint.
>>>>
>>>> Dave
>>>>
>>>>> Trying to summarize things somewhat here and focus in hopefully
>>>>> towards some decision. There's basically an idea on the table to add an AS
>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be a JSON
>>>>> object which contains endpoints that a client doing MTLS would use rather
>>>>> than the regular endpoints. A straw-man example might look like this (with
>>>>> The arguments against it seem to be 1) the bad UX isn't really that
>>>>> bad and/or will only happen to a subset of users 2) there are other things
>>>>> that can be done, such as 307ing or renegotiation/post-handshake client
>>>>> auth, to avoid the bad UX.
>>>>>
>>>>>> > 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
>>>>>> The primary use is to set policy to rely on device level management
>>>>>> in controlled environments like enterprises when available. So an AS may
>>>>>> try to detect a client certificate as an indicator of a managed device, use