Filip did some testing along these lines awhile back. Although I think he was more focused on the other side of things by instructing the fetch/XHR request to omit sending credentials. The behavior he saw was that he wasn't able to suppress the certificate selection prompting as expected or hoped. But I don't think he'd say that the tests were exhaustive or conclusive (and again wasn't about the ACAC header so much as the request API). Also I wouldn't be surprised if browser implementations of a rather niche and software layer crossing part of a living standard aren't fully baked. I mean, I think the browser has to establish a TLS connection where it will be asked for client certs during the handshake in order to send the preflight request so as to get back (or not) the CORS Access-Control headers. So I guess it would have to ignore the CertificateRequest message in the handshake (and hope the server considers certs optional) and then, if the preflight response had ACAC:true, reestablish the TLS connection and do cert selection prompting before sending the actual request. Or if no ACAC:true header, then keep using the prior connection. Maybe I've gone off the rails there but I think the point was that it's complicated and so some rough edges on the implementations in the wild or misunderstanding of expected behavior aren't out of the question. Also I think you need something more on a POST request to the token endpoint, like some custom header, to trigger the whole preflight dance. A simple POST request is not preflighted so the ACAC isn't about sending credentials but about the browser rejecting a response that does not have the ACAC:true header and not making the response available to the invoking script.
Anyway, with that rambling out of the way, I think that Neil's suggestion falls into the category of things (along with things like method/body preserving redirects, renegotiation, post-handshake client auth) that might be usable to suppress or avoid browser cert selection UX in the arguably not too common cases it happens. On Tue, Feb 5, 2019 at 9:17 AM Neil Madden <neil.mad...@forgerock.com> wrote: > I’m less and less convinced that a redirect is the best way to do this. > > I was reading the WHATWG Fetch spec yesterday, in particular the entries > about CORS, and realised that for cross-origin requests TLS client > certificates are treated as credentials just like cookies: > https://fetch.spec.whatwg.org/#credentials > > Credentials are HTTP cookies, TLS client certificates, and > authentication entries (for HTTP authentication) > > So assuming that web browser clients calling the token endpoint will most > likely be calling cross-origin, then it seems that client certificates > won’t be sent anyway unless Access-Control-Allow-Credentials: true is > returned from the preflight request. Given that calls to the token endpoint > shouldn’t generally require cookies, then it seems likely that you can just > *not* allow credentials in the CORS response and therefore not have any > problem with prompting users for certificates. (Note that you can still > manually set the Authorization header without ACAC set to true, you just > have to whitelist that header in the AC-Allowed-Headers response). > > I haven’t got time to test it myself right now, but if so that seems like > it side-steps the issue pretty neatly. Configure the token endpoint to ask > for, but not require, client certs, and then make sure you don’t return > Access-Control-Allow-Credentials: true on CORS preflight requests to that > endpoint. > > — Neil > > > On 5 Feb 2019, at 15:21, Justin Richer <jric...@mit.edu> wrote: > > > > +1 to David. If it’s a redirect, 307 is more appropriate. It’s up to the > AS to decide if the client should do MTLS or not, if there’s an option. > > > > — Justin > > > >> On Feb 4, 2019, at 12:17 PM, David Waite <da...@alkaline-solutions.com> > wrote: > >> > >> My understanding is that a permanent redirect would be telling the > client (and any other clients getting cached results from an intermediary) > to now stop using the original endpoint in perpetuity for all cases. I > don’t think that is appropriate (in the general case) for an endpoint with > request processing business logic behind it, since that logic may change > over time. > >> > >> -DW > >> > >>> On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org> wrote: > >>> > >>> Yeah, probably. > >>> > >>> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <neil.mad...@forgerock.com> > wrote: > >>> If we go down the 307 route, shouldn’t it rather be a 308 (permanent) > redirect? It seems unnecessary for the client to keep trying the original > endpoint or have to remember cache-control/expires timeouts. > >>> > >>> — Neil > >> > >> _______________________________________________ > >> 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
