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

Justin Richer <> Wed, 23 October 2019 14:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40BB21201EA for <>; Wed, 23 Oct 2019 07:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.863
X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lEhp528t6uo7 for <>; Wed, 23 Oct 2019 07:13:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B63412082E for <>; Wed, 23 Oct 2019 07:13:16 -0700 (PDT)
Received: from (OC11EXEDGE2.EXCHANGE.MIT.EDU []) by (8.14.7/8.12.4) with ESMTP id x9NED20W021807; Wed, 23 Oct 2019 10:13:15 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 23 Oct 2019 10:12:59 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 Oct 2019 10:13:04 -0400
Received: from ([]) by ([]) with mapi id 15.00.1365.000; Wed, 23 Oct 2019 10:13:04 -0400
From: Justin Richer <>
To: Brian Campbell <>
CC: Benjamin J Kaduk <>, oauth <>
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt
Thread-Index: AQHVfEpgATAtVF2gR02iNTFB3cSWYKddpSkAgAcNagCAA83CgIAAIhuA
Date: Wed, 23 Oct 2019 14:13:04 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8A8B88929D164210BC1347B5D7859976mitedu_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Oct 2019 14:13:18 -0000

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 <<>> 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 <<>> 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.


OAuth mailing list<>

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<>