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

Brian Campbell <> Mon, 04 November 2019 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6FE8120274 for <>; Mon, 4 Nov 2019 05:40:05 -0800 (PST)
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 PlpWFHvYq8DZ for <>; Mon, 4 Nov 2019 05:40:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D601120869 for <>; Mon, 4 Nov 2019 05:40:03 -0800 (PST)
Received: by with SMTP id k15so5522324lja.3 for <>; Mon, 04 Nov 2019 05:40:03 -0800 (PST)
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=NrS8C2DcuFIXvjYguZSL+1V2FfHg6mqftOHB+ZfWiGs=; b=I3vHnrs7m9R8qi2of2+6sqApw2Sj7dTrtRTSUD8PrvRVoAL/JUNn0+g70xuUCv30jO iRtkyfxFWAk1P2LG0SrENEjeqUr/u3l4yECbchAKVaw8CIsaHZOjVZZ/iqbJ/hO/Meh4 +VMKrzCLGQyKx7Buwj0RDnLU9VnqYpeCRg4Lk=
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=NrS8C2DcuFIXvjYguZSL+1V2FfHg6mqftOHB+ZfWiGs=; b=fWAG1C5IABNdMjM7ZIuu+iXMnuKer6urGW3a3sf6S8ouQrtP4JpF5FQZCSH86YG/kF M+MygoXvYs9kUudRdMCzIMUoAUU9YwHV2OkMefbI46WHa9axBFgijbG6oUPKTsC1FWfK QxOh2abMeAxFeLKlzsdmellFEmm5JGAdyFYSQkO/u19AxlruOfrfEbBMl9VoT3xMYhjZ c1L/d+/ggkyE8SUPgzrYRJhHfyxd7LP0JJ5fH0zcXuEjzeQeKJpYl2NSG9k5eIRU2ZPa Z7TpamKmD+8blISuVAZyix9vnAteUNSC264r2kNWuBa3eCVhnNfz6WcbH4xY1MgCQ7d2 3lYQ==
X-Gm-Message-State: APjAAAVZ1etozuU1CSRTJ11sJOiV6NS7C85Bjb0KW49+91H9RIeC0JeT ZHF5hOEm1WuirE/jUG7vUtMYLaLQWIyMbLxEKZitAReeNboODZidlT1EF9lxzQSMGcBMUXKEVMA sJL4L+zX4IGRZuw==
X-Google-Smtp-Source: APXvYqwCUitXl53j0/h0yw3/LAdJTo5PA2sbmALOTXCtPy4JSXP0wQA/N6bfu5pqFHZLqp5lWyiuozPJ/lXZtkH6a3A=
X-Received: by 2002:a2e:8784:: with SMTP id n4mr3140397lji.230.1572874801741; Mon, 04 Nov 2019 05:40:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Mon, 04 Nov 2019 06:39:35 -0700
Message-ID: <>
To: Travis Spencer <>
Cc: Benjamin Kaduk <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000d59a780596857385"
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: Mon, 04 Nov 2019 13:40:09 -0000

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

> On Wed, Oct 23, 2019 at 2:11 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.
> 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._