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

Travis Spencer <> Sat, 28 September 2019 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07358120115 for <>; Sat, 28 Sep 2019 06:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FmeUPwHiPs2P for <>; Sat, 28 Sep 2019 06:36:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B2FD12001E for <>; Sat, 28 Sep 2019 06:36:16 -0700 (PDT)
Received: by with SMTP id x64so1897741ywg.3 for <>; Sat, 28 Sep 2019 06:36:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xfz8dOd+jyDYg7DccPcDuFUiFv1WQIay87GBtC6N2Fg=; b=h9AqCAE8cZvxaaqtj7uRoXFUUJXuu0NMQtXSeu1JpGIpIKBgiCm9oQD0pKCRCoavPz KWNlz6WLcLJyg3w6sQp+JymCAZTwyjEqXorpvU3RqiESIh7hntFaId0XwAlsuH7X8vGM YOFZ2RKSd57VxQWnRbdrUlS7bIiGkO7bTmB9IVdAlDvhfioMbzQm3CWUzCM8V1UI2Mxb nAAvaCrPshQiICWWQP5BPYAf0FFVq1dd4BkQVvKnvQB1yNnxCbgpj3+LxSl/Z1aawm9i jMzRpt7DnVSjB/U2hVy86RrMo9HECRt5oTf52nzD92OzyNh00o/m8PjKow2bpQJaGj3a pBjA==
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=xfz8dOd+jyDYg7DccPcDuFUiFv1WQIay87GBtC6N2Fg=; b=G4s+QoqZor+mxBflSkbL4cyFJggkrqMtSFOymoF7/agv7VMA5KBGdAwwimfNY38AJT EN6bQCNnySADf2QHR4U6mASYCoch1RuZLM8+03UsCU2NRrKTKjqm5OFtgLPdccZe3028 i2RGctwzXQNOie9wa39yC2lZSmMZprSEtjWyNetR+RDbO00YLCZK06XPJGC4mi/Caxdq oO+9TXSUw1U5U7yQGKwwyXguFvOikY17mkD++UPY7N2XVRBfyz+5H/AjSS00E/NNMB0G DZsQCJC1APCp0qucDlecn4ZLNopLKZ9dIukOX+pbsC5NHXxnU9M+6ClvgtxmCOtCl+SF FKog==
X-Gm-Message-State: APjAAAVybqpw/5LTuksa29vXZXS854N3KEHZCjoVhYIcDvAmtlSRfU58 V3fOFtzM3Fv7Lhb0hD5YzefYpwNBUpfgFYzBKndFDinwSSM=
X-Google-Smtp-Source: APXvYqySa6r0fqsRhjMYXxWpP8ZavrU1opSSIMSZScGwu6JEX8fGjOh0/isCEG0mip4UQVZyOKz0v+4RLoJ1qYHOEOA=
X-Received: by 2002:a81:c202:: with SMTP id z2mr6241712ywc.47.1569677774158; Sat, 28 Sep 2019 06:36:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Travis Spencer <>
Date: Sat, 28 Sep 2019 15:36:02 +0200
Message-ID: <>
To: Benjamin Kaduk <>
Cc: oauth <>
Content-Type: text/plain; charset="UTF-8"
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: Sat, 28 Sep 2019 13:36:18 -0000

On Sat, Sep 28, 2019 at 12:51 AM Benjamin Kaduk <> wrote:
> On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
> > * Last but certainly not least is the restriction that the current
> > version places on disallowing of the introspection JWT response as an
> > access token. This is done in numerous places (the note in section 5,
> > 8.1, etc.). I understand that there are some objection to this usage,
> > but we have had this protocol deployed for years, and it's running in
> > dozens of customer's facilities. This will break real applications of
> > this specification without a clear alternative. As we discussed in
> > London last year at the IETF meeting, token exchange isn't a viable
> > alternative (even still in its current draft form to the best of my
> > knowledge). Without a workable alternative to move to, I emphatically
> > but humbly request that this specification remove this restriction.
> I don't think I was in the London session, so would you mind saying a bit
> more about why token exchange isn't viable for your scenario?

A few reasons:

1. There is no way to do content negotiation in token exchange as
there is in this protocol. For some clients, this is preferable and

2. The desired response body is not a simple stream that can be
processed quickly and efficiently (like the one defined by this
protocol). The exchanged token must be parsed out of the token
exchange response.

3. Creating the payload of the request is slightly more involved, and
the client is often limited in its capabilities[1]

4. HTTP cache controls that are tied to the input token validity
period can't be applied as easily to the token endpoint response
because the client has to parse the token exchange response (slower)
or cache the entire reply (more memory)

5. The HTTP status code I mentioned in my last mail isn't defined as a
way of communicating to the client that the input token is expired.
This provides a client with the fastest way of knowing that a token is
expired (that I can determine at least).

6. Migration of the clients and deployments using JWT introspection
response will be costly and time consuming with little gain (in my
judgement at least)

> As an AD, I support the efforts to be explicit about what token flow/usage
> is being defined, which in effect means keeping introspection just
> introspection and not "producing new tokens".

I can appreciate this, but I don't see what I'm proposing as producing
new tokens. Instead, I see it as re-encoding the same token in a
different form. The subject is the same, the audience(s) is/are the
same, the expiration time is the same, the claims are the same.
They're just signed and have a new issuance time. In our
implementation, the original token and the JWT version both stem from
the same "delegation", so both are traceable back to the same end-user
authorization, implying that both are invalidated when that delegation
is expired or is revoked (which the end user can do or the client can
do if it revokes a refresh token if it was given one). The use case
we're using this protocol for is about re-encoding an access token in
another form that is also used as an access token.

[1] This argument is admittedly weak, as discussed at the IETF meeting.