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

[Filip Skokan <[e-mail]>]

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=
[e-mail]> 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?
>
> What do folks (including Ben & Neil) think?
>
> On Fri, Jan 4, 2019 at 2:55 PM Benjamin Kaduk <[e-mail]> wrote:
>
>> On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote:
>> > 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.
>>
>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>