On the assumption that this is likely to be a requirement from customers, I’d be in favour of a new server metadata field. My favourite bikeshed colour would be:
tls_client_auth_token_endpoint On another metadata-related note, given that the additional security of certificate-bound access tokens vanishes if the resource server doesn’t understand and enforce the certificate-binding associated with the access token, is there a general need for a client to be able to discover if any given RS does actually support this? Otherwise the whole scheme “fails open” in that the access token silently degrades to a normal bearer token. Or do we consider it unlikely that an RS is going to accept a TLS client certificate without supporting this? — 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
