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
