The goal of the draft-ietf-oauth-mtls document is to define the pieces needed for interoperability between the OAuth client, AS and RS. It's not intended to define or prescribe the internal implementation details of those entities. Although this particular implementation detail came up enough to make it into the document with https://tools.ietf.org/html/draft-ietf-oauth-mtls-17#section-6.5 saying it's possible but the specifics are explicitly out of scope. It would have made sense to reference something there informatively, if such a thing existed. But as far as I know there's not anything that fits the bill. So draft-ietf-oauth-mtls, which is currently in the RFC editor's quere so kinda beyond accepting changes at this point, says that "how the client certificate metadata is securely communicated between the intermediary and the application server in this case is out of scope of this specification."
On Fri, Nov 1, 2019 at 11:02 AM Travis Spencer <travis.spen...@curity.io> wrote: > On Wed, Oct 23, 2019 at 2:11 PM Brian Campbell > <bcampb...@pingidentity.com> wrote: > > I agree with Ben here that it's not at all clear that the OAuth MTLS > document should have defined a protocol from proxy to backend. > > Shouldn't it at least normalitvely reference some other spec then? If > that reference is not defined before this draft is finalized, one > could say they comply with the final mTLS spec but in a > non-interoperable way. > -- _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
