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

Brian Campbell <> Wed, 23 October 2019 12:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02DB9120837 for <>; Wed, 23 Oct 2019 05:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aFOFMGd8sHo6 for <>; Wed, 23 Oct 2019 05:11:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 866BB120815 for <>; Wed, 23 Oct 2019 05:11:27 -0700 (PDT)
Received: by with SMTP id u22so2838509lji.7 for <>; Wed, 23 Oct 2019 05:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qu+nAApTvA5AnN1mDhhdfayx0Ac8pHfTWkC29jwIkD0=; b=LM0d+v5fS1DRNwVjm0YFEegvjTjHcui7j6zRBeFsJk12w/faARXrtjQi4hvZGB32TC U277/oOXK8YY7+qM7daPz+vgrUOMQ44pCUBX8iShjjwEJ2tRemMJ+HHDZbvx80JUEEVS 4ibGY5r6QgVqKWPLf2pw0U9w5T0+r4HTTKcqI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qu+nAApTvA5AnN1mDhhdfayx0Ac8pHfTWkC29jwIkD0=; b=VPfbi+p/vOroAjy39NRCBUjon3870dgOY+yB+/S47pPJvLQbejGI6pOEfRv4RxnBAn gb/ga5Q9003pj7QRztM7m5zbUjh5hM+hqSl0hc+v5vZgSLfeDW7s6+vqtOQuDJIOzdZq iWhT+OCVz6UiZZbfk5U1QbBRRsuDLEJOPWvIcXkaZ5rbcdWItdTIQ7xBD2dZ94ElU/la +XEljQdDtbz6h0DcfkL666cxfTTJa2lS+MvS7dt/Hd7gaQl9ypppdECRwSOUBsHRncTL DHPAHnEFhnu+1dhqE/QVTgpB5zD6RYAtj+7E5or91GuQDqP+otYQBgimX6YrXeR0ROSC +RjQ==
X-Gm-Message-State: APjAAAXeUzj02FsTR+6aOdIcRa4zCuqFKNJ46YnDvb3uZql8SY4+MB5k lsSnRm0m5/2OKp6xF0D4LRTaBjePwNN8jEtGpEfs6SDgokmWz0JAk+uymy6P+EyJOMyhjaf/8bd jm62oCduxEKJLcg==
X-Google-Smtp-Source: APXvYqy1/VfT/2uAk5MQdvPvwVA90QIKKFjN8i2Hj1ITELto+u28w5obqac3XERlq2unno3xvdorpIX9t5S6Mn8i9nc=
X-Received: by 2002:a2e:8204:: with SMTP id w4mr22344439ljg.3.1571832685504; Wed, 23 Oct 2019 05:11:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Wed, 23 Oct 2019 06:10:59 -0600
Message-ID: <>
To: Benjamin Kaduk <>
Cc: Travis Spencer <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000ddd32f059592d09b"
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 12:11:30 -0000

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.
> -Ben
> _______________________________________________
> 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._