Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

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.

— Justin

On Oct 23, 2019, at 2:10 PM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org<mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>> 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. I'd go so far as to say it's well outside the scope of the document and even the working group. Admittedly It would be nice if such a thing existed but it would have much wider applicability than one narrow profile of OAuth.

On Sun, Oct 20, 2019 at 8:06 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Just on one narrow point:

On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote:
> On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
> > Open: How would one implement sender constrained access tokens in that case? I’m asking since the receiving RS obviously has no access to the information from the TLS handshake since TLS termination happens at the proxy (or even in before the request hits the proxy). The RS would need to get provided with the cert fingerprint via a trustworthy header, i.e.. the RS must be aware of the fact it sits behind a proxy.
>
> This is unfortunately the typical case even with the mTLS draft. This
> is because SSL is almost never terminated by the AS; in my experience,
> TLS termination is instead handled by some very fast proxy.[1] In such
> cases, the proxy will pass the cert through to the AS in some
> undefined HTTP header with some undefined encoding. The mTLS spec
> should have defined this IMO, as it prevents interop for a primary use
> case -- sender constrained tokens.

It's not clear to me that mTLS should have defined a protocol from proxy to
backend; that seems like it could be a fairly generic thing and I know of
several people that are working on similar things, to one degree or
another.  draft-schwartz-tls-lb is the example that I can most easily find
in my archives; though it's working with non-TLS-terminating cases, there
is probably some commonality with TLS-terminating cases as well.

-Ben

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto: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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth