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 <neil.mad...@forgerock.com> 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 > > On 7 Jan 2019, at 17:21, Brian Campbell <bcampb...@pingidentity.com> > 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.* > > -- _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
