Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

Neil Madden <> Fri, 12 February 2021 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 961C23A1371 for <>; Fri, 12 Feb 2021 00:09:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 pvcp3VbtRJrl for <>; Fri, 12 Feb 2021 00:09:08 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 729263A1370 for <>; Fri, 12 Feb 2021 00:09:08 -0800 (PST)
Received: by with SMTP id i8so14125189ejc.7 for <>; Fri, 12 Feb 2021 00:09:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=bp+zqZEFLmkbNxGPr7w7yMvVM9Xv7RKJDtSWOckUdIQ=; b=OrKbeW3zA/cOMnh3j4JsSJL5Doz4VkAUksjvF2O9EvHFu3J1sCoBSJ06feH1rv9ruW WAkQXsyV1ee8zeZrS2GYM/nRmXeUFsVhBUIjlw8n8Ry9PEuJ6pr4dfXqhWqYLfsWAloX wfRQfY4I8V9wJ05rJH5doek+wd1PY+wEbQNQw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=bp+zqZEFLmkbNxGPr7w7yMvVM9Xv7RKJDtSWOckUdIQ=; b=memlU1mU6n5t78Dlj9pfVGxak0RBAcX3Tz1/wm/vsJKfK0H3FnV7HGSsm6sroVKRoT vQ1yQDW2bq4YoGvGTeCnjewMisKCjcy0FalkqKGlabIsyURp5cn8Mm+V8MAZ8wv8yROK Sv+v6pV85a6vzPWMZpSrW9OUj5W5MqKxjCdV36RXrrB04Enh0J4umND3NU8LeIcY8McY ualfXi8EwHNkPEtK4XtIoqgTtONro5LdKsSHXalzsY7el1Ur6JpyEhSj8BMuc1CqQjrm j+Cnd6CKBWqGdKGXytm5qrQluQNBsC2QNSEeSEhKIPwoJP7HeyLgyv+W5gJXV+V2UmL+ VlTA==
X-Gm-Message-State: AOAM533J2CY19OEzoqkriFfyvOr+rewzEmgmDch4BstGOVxh9R5P5QgK 2XQnoer4watxlFf/evvWDjHn9FvD3RkWStwqZUuKZBxr8CkQHDcNeY63G3XoTfiRal4XBv1EUg= =
X-Google-Smtp-Source: ABdhPJwEWFS84mkcHIxSmTdoy+bZO66qn0wUl47BD5SjGtSQONY36H3g4tD1uZcZIagc+Y9PCd0L+w==
X-Received: by 2002:a17:907:9702:: with SMTP id jg2mr1914321ejc.48.1613117346725; Fri, 12 Feb 2021 00:09:06 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id r23sm5825535ejd.56.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Feb 2021 00:09:06 -0800 (PST)
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Feb 2021 08:09:05 +0000
Message-Id: <>
References: <>
Cc: oauth <>,
In-Reply-To: <>
To: Andrii Deinega <>
X-Mailer: iPhone Mail (18C66)
Content-Type: multipart/alternative; boundary="Apple-Mail-F3F8DE8F-E853-42AC-9C07-08529D60499B"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce
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: Fri, 12 Feb 2021 08:09:11 -0000

> On 11 Feb 2021, at 21:43, Andrii Deinega <> wrote:
> Thank you for the response! Unfortunately, I'm still not convinced that there is no need for nonce.
> Based on the draft, I don't know how it's possible to achieve a “stronger assurance that the authorizationserver issued the token introspection response for an access token, includingcases where the authorization server assumes liability for the content of thetoken introspection response” if we can't guarantee that a client will always get the response to its initial introspect request, or in other words, old communications can be never reused (the iat claim isn't going to be sufficient for that).

The whole point about liability is being able to establish it after the fact. A nonce is only meaningful within the initial interaction and so is no help at all for establishing liability. 

> Let's put aside those attackers for a moment and say we experience some awfully wrong caching issues that can happen anywhere between an AS and a client... where the client gets a cached response for its previous requests which isn't expected. How can it be prevented?

1. TLS. 2. Cache-Control. 

— Neil

ForgeRock values your Privacy <>