You might want to look at RFC7239, which is trying to address the issue of the loss of information by proxies. https://tools.ietf.org/html/rfc7239
The document does not have a parameter to carry the client certificate information, but it allows for new parameters to be defined. Would that help in this case? Regards, Rifaat On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk <[email protected]> wrote: > On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote: > > I also agree. Would it be possible to get this pushed to http or tls? > It > > would be more appropriate there, and very helpful to have a general > spec > > for this. > > I think it's possible to get such work done in one of those places, but > first someone has to actually write a draft. Barring that, a HotRFC or > secdispatch slot in Singapore would probably be good for drumming up > interest. In related news, I am told that draft-duke-quic-load-balancers > had some time in the QUIC interim this month, and may be moving towards > adoption, so time may be short if we want to have a fully general solution. > > -Ben > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
