I claim no particular expertise here and it's admittedly been a long time since I actually tested the behavior myself. But in my prior experience there were browsers that would prompt the user even when there were no certificates/keys configured for or available to the browser.
On Mon, Dec 17, 2018 at 3:37 PM Filip Skokan <panva...@gmail.com> wrote: > Correct. If there are certs installed on the device the browsers are > likely going to prompt. > > Having at least one CA configured together with optional_no_ca (even if > its a CA noone ever has certs for) additionally omits the prompt for some > client configurations. > > Odesláno z iPhonu > > 17. 12. 2018 v 23:10, John Bradley <ve7...@ve7jtb.com>: > > > I think that works for those browsers if no certificates are installed > for the browser. We should test, but I think if any certificates are > available to the browser then it will prompt. > > > > John B. > > > > > >> On 12/17/2018 1:52 PM, Neil Madden wrote: > >> I am currently running a Tomcat instance that I have configured to > support, but not demand, client certificates using the > certificateVerification=“optionalNoCA” setting. With this config I am able > to authenticate a confidential client using mTLS, and yet connecting to the > same server over HTTPS in either Safari or Chrome on Mac does not prompt me > for any certificate. I don’t have any client certificates configured in my > browser, so does this only happen if you do? > >> > >> Depending on the deployment scenario, it may also be possible to > terminate TLS at a proxy and use a separate proxy for (intranet) mTLS > clients vs public clients, but that may not suit every deployment. > >> > >> — Neil > >> > >>> On 17 Dec 2018, at 20:26, Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org> wrote: > >>> > >>> While there's been some disagreement about the specific wording etc., > there does seem to be general consensus coming out of this WG to, in one > form or another, recommend against the use of the implicit grant in favor > of authorization code. In order to follow that recommendation, in-browser > JavaScript clients will need to use XHR/fetch (and likely CORS) to make > requests directly to the token endpoint. > >>> > >>> Meanwhile there is the MTLS document utilizes TLS client certificates > at the token endpoint for client authentication and/or certificate bound > access tokens. The security BCP draft even recommends sender/key > constrained access tokens and MTLS is close to the only viable way to do > that at this time. > >>> > >>> Unfortunately, however, these two things don't play very nice > together. When a browser makes a TLS connection where a client cert is > requested by the server in the handshake, even when client certificates are > optional and even when it's fetch/XHR, most/many/all browsers will throw up > some kind of certificate selection interface to the user. Which is > typically a very very bad user experience. From a practical standpoint, > this means that a single deployment cannot really support the MTLS draft > and have in-browser JavaScript clients using authorization code at the same > time. > >>> > >>> In order to address the conflict here, I'd propose that the MTLS draft > introduce a new optional AS metadata parameter that is an MTLS enabled > token endpoint alias. Clients that are doing MTLS client authentication > and/or certificate bound access tokens would/should/must use the > alternative token endpoint when present in the AS's metadata. While all > other clients continue to use the standard token endpoint as they always > have. This would allow for an AS to deploy an alternative token endpoint > alias on a distinct host or port where it will request client certs in the > TLS handshake for OAuth clients that use it while keeping the regular token > endpoint as it normally is for other clients, especially in-browser > JavaScript clients. > >>> > >>> Thoughts, objections, agreements, etc., on this proposal? > >>> > >>> PS Bikeshedding on a name for the metadata parameter is also welcome. > Some ideas to start: > >>> token_endpoint_mtls_alias > >>> token_endpoint_mtls > >>> mtls_token_endpoint_alias > >>> mtls_token_endpoint > >>> alt_token_endpoint_mtls > >>> mtls_token_endpoint_alt > >>> > a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use > >>> equally_poor_idea_here > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> 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 > > > > _______________________________________________ > > 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 > -- _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
