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= 40pingidentity....@dmarc.ietf.org> 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 <ka...@mit.edu> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
